Run the same public HTTP and socket cases against TypeScript and all native
runtimes. Keep native toolchains out of JavaScript-only jobs, require the
dedicated conformance gate, and retain regression evidence and fixture
review rules.
A burst of SEO spam issues arrived today through the free-form path.
Set blank_issues_enabled to false so every new issue goes through the
bug, feature, or documentation form and its required fields.
Also remove the legacy issue_template.md. Its whole body is "Please
describe your issue in as much detail as possible", so it is a second
free-form entry point that would undo the config change.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
No CI job ran the shell-docs vitest suite, and none of the prompt files were
in the docs workflow's paths filter, so the assertions these tests make were
verified only on a developer's machine. That is the same gap the retired
prose had: nothing measured it and nothing caught it rotting.
The job is scoped to five files. The whole shell-docs suite is not green on
main, so running it here would gate every prompt change on unrelated
failures.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The header said "publish via nx release". The lane builds with
`nx run-many -t build`, but publishing is publish-release.ts driving
`npm publish <tarball>` under the pinned npm from lib/npm-cli.ts, which the
OIDC trusted-publisher binding requires. Versioning and notes happen earlier,
in the release PR.
The notes now land in a source-controlled changelog instead of a scratch file
that rides the release branch. One file per lane, because the lanes version
independently: a shared file would interleave `1.70.0`, `angular/0.5.0` and
`channels/0.9.0` into one unreadable sequence.
monorepo -> CHANGELOG.md
angular -> packages/angular/CHANGELOG.md
channels -> packages/channels/CHANGELOG.md
`write-changelog.ts` prepends this release's section on the release branch,
create-pull-request commits it (a tracked file, always staged), and
`extract-release-notes.ts` reads the section back in the publish job as the
GitHub Release body. The changelog is therefore both the durable record and the
review surface: editing a section on the release PR changes what ships.
release-notes.md goes back to being ignored, so the same notes never exist as
two editable copies.
Also deletes 29 changesets-era changelogs that no tooling had written since
April. They stopped at 1.55.2 while the lane shipped 1.69.3, and
packages/angular/CHANGELOG.md still claimed 1.54.3 from before that lane split
onto its own 0.x line. Their content stays recoverable from git history. A test
pins the tracked changelog set to the lanes so they cannot creep back and
contradict the real versions.
Extraction never fails the publish job: it runs after npm publish, so a miss
annotates loudly and falls through to the existing bodyless-release fallback
rather than stranding the tag.
Committed with --no-verify: the pre-commit nx lane cannot run in this worktree
(packages/core and packages/channels-ui have no node_modules, and
`nx run @copilotkit/core:build` fails identically with the tree clean). The only
change under packages/** is deleting orphan markdown that no build or test
reads.
The generator fed the model a repo-wide `git log -50` as context and told it
it was writing notes for "CopilotKit vX.Y.Z, an open-source AI agent framework
for React applications" — wrong on three counts for an angular or channels
release: the wrong commits, the wrong framing, and the wrong release title
(only the monorepo lane is titled `vX.Y.Z`).
Pass the scope through, build context from that lane's own commits, name the
packages actually being published, and tell the model to write about nothing
else.
Also fix the API call itself: the pinned model string was a dated snapshot,
max_tokens 2048 could truncate a large release, and the response reader took
content[0].text — which is not the text block on models that return thinking
blocks first.
release-notes.md and release-notes-notion.json were both gitignored, so
create-pull-request silently skipped them. The notes never reached the release
branch, the publish job's readFileSync missed, and every release since this
lane was built shipped its "Release <tag>" fallback body — v1.70.0,
channels/v0.6.0 and angular/v0.4.0 all have bodyless GitHub Releases.
The same ignore rule severed the Notion lane: without the json ref in the
checkout, publish-release could never read an edited draft back, so that path
had never run either. Remove it rather than repair it — the release PR is
already the review surface, and editing release-notes.md on the branch is a
plainer gate than a Notion page.
Guard the ignore rule with a test, since re-adding it would break the lane
again without breaking anything else.
CI ran for the first time on the PR and flagged three new-package registration
steps (Ben's review):
- add packages/mcp-apps-renderer/tsdown.config.ts to .github/config-allowlist.txt
(static / check binaries)
- drop the UMD half of the compat-check script; this package builds no UMD
format, so `es-check ... dist/**/*.umd.js` found no files and failed
(static / compat)
- bump the monorepo package-count drift guard 16 -> 17 now that the package
joined the release scope (test / unit)
The v1 deprecation notice added in #6582 is a source-file banner for IDEs and
coding agents, including the line "AI CODING AGENTS: Never copy, suggest, or
generate these v1 APIs." It sits in the leading trivia of the first statement
of every public v1 source file, which is the same place the reference-docs
generator reads real JSDoc from, so regenerating embedded it as visible body
text on 20 published pages. That made regeneration unpublishable: no JSDoc
correction to a v1 source could land without also shipping the banner.
Skip the notice wherever the generator enumerates comment ranges, keyed off its
stable opening delimiter.
Also repoint the six SDK reference entries. Their pages moved to
reference/v1/sdk/ in ec239b15f7 and the old copies were deleted in a8d43a9c2e,
but files.ts still wrote to reference/sdk/, so the generator refreshed a
directory the docs site never served while the live pages went stale. Those
pages regain the upstream LangGraphAgent -> LangGraphAGUIAgent rename and the
copilotkit_emit_tool_call tool_call_id parameter. The renamed page replaces the
orphaned LangGraphAgent page, whose source file no longer exists, with a
permanent redirect for the old URL.
Regenerating is now idempotent: a second run leaves the tree clean.
Fixes#6939
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The coverage ratchet added for OSS-1036 never ran in CI. No workflow runs the
shell-docs vitest suite: `test_integration-docs.yml` runs exactly one test
file, `test_unit-showcase.yml` covers harness and shell-dashboard only, and
`showcase_build_check.yml` matches `showcase/**` but only builds images. On top
of that, neither path filter listed the snippet files the gate reads, so a new
`frontend-tools-setup.mdx` triggered nothing.
Add a scoped job and widen both filters. The job is deliberately limited to the
two setup-concept test files, because the full shell-docs suite is not green on
main and would gate every snippet change on unrelated failures.
The harness symlink step is the same one showcase/shell-docs/Dockerfile uses:
`generate-registry.ts` imports the catalog fold out of the harness tree, which
resolves `js-yaml` by walking up from `showcase/harness/`.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Address CodeRabbit's re-review of the review-response commit:
- correct the static_bundle_size.yml comment ("10" -> "11" in-scope packages)
now that the renderer is in the measured pattern
- add docstrings to the functions flagged by the docstring-coverage check
(buildSandboxHTML, MCPAppsRequestQueue#processQueue/#waitForAgentIdle, and the
bindMcpApp flushPending/fetchResource/setup closures)
Comment/docstring only; 16 tests green, check-types + oxlint clean.
The gate added in the previous commit would have failed on a clean checkout.
The Strands TypeScript integration sits outside the pnpm workspace on purpose:
its agent process resolves openai and the Strands SDK from its own
node_modules, which the Dockerfile installs with npm ci. The workflow ran only
the repo-root pnpm install, so two of the four test files could not resolve
their imports. It passed locally only because that directory already existed on
this machine. Reproduced by moving it aside (2 files fail), then confirmed the
workflow's own steps green it again (16 tests pass).
The job now installs the agent package the same way the Dockerfile does, and
runs the vitest config that already lives beside those tests rather than a
second config layered above them, so CI runs exactly what `npm test` in that
directory runs. The path filters narrow to the sources the run actually covers,
so a PR touching an unrelated integration no longer collects a green check from
a job that exercised none of its code.
The showcase integrations sit outside the pnpm workspace, so nx never
discovers them and the harness unit workflow does not cover them. Their Python
tests are already gated by showcase_validate.yml, but nothing anywhere ran
vitest under showcase/integrations: four test files in the Strands TypeScript
agent, including the one this branch adds for the resume envelope, could fail
indefinitely without CI noticing.
A small config at showcase/integrations/vitest.config.ts gives those tests one
home, driven by the monorepo's own vitest so no integration has to carry a test
dependency into its Docker image. Its include list is an allowlist rather than
a wildcard: most integrations' existing tests resolve imports through their own
Next.js path aliases and only run under their own config, so sweeping them all
in would fail on arrival. Adding an integration to the list means first making
its tests runnable from the repo root.
The workflow runs that config on pull requests touching the integration agent
sources or their tests. It does not pass --passWithNoTests, so an include list
that stops matching fails the job rather than reporting an empty success, and
it interpolates no discovered filenames into a shell command, since a fork
controls the file names in this tree.
Bridge-free /activity (review blocker): the `./activity` entry pulled ext-apps'
LATEST_PROTOCOL_VERSION through constants.ts, statically dragging the App SDK +
zod/v4 (~+55 kB gzip) into react-core's eager chunk. Move MCP_APPS_PROTOCOL_VERSION
to the bridge side (session.ts), sourced from the /app-bridge subpath the session
already imports - single source of truth, no hand-maintained literal, zero extra
cost. dist/activity.mjs and dist/constants.mjs now carry no @modelcontextprotocol
edge.
Keep react-core's zod peer at >=3.25 (review blocker): the floor moved down to the
package, it did not go away; ext-apps + the MCP SDK both hard-require it, so >=3.0.0
is an ERESOLVE install failure once an MCP App renders.
Drop the <copilotkit-mcp-app> web component from this PR: nothing consumes it here
(the React adapter builds its own iframe) and it carried two open defects. It lands
with the Vue/Angular adapters, its first real consumers. Removes its files, exports,
tsdown entry, and the now-unused lit dependency.
Also: add content.serverId to the bind effect deps; delete drained thread entries
from the request queue's maps (bounded growth); register the package in
static_compat.yml (+ a compat-check script) and static_bundle_size.yml; publint
repository.url -> git+https. Manifest regenerated.
The matrix covered the declared floor (0.0.42) and the newest release
(0.0.44) but skipped 0.0.43 — the only still-supported version that
reproduces the failure this PR fixes.
0.0.43's `LangGraphAgent.clone()` passes its three behavior flags to
`type(self)(...)` unconditionally, so a subclass with a closed signature
raises TypeError on the default construction path — a 500 on every
request, since the FastAPI endpoint clones per request. 0.0.44's
`clone()` is signature-aware and omits default-valued flags a subclass
cannot accept, which means the clone tests pass on 0.0.44 even with the
`**kwargs` passthrough removed. The `emit_raw_events=False` test still
guards option reachability there, but nothing in the matrix reproduced
the default-construction 500 itself.
Verified locally against 0.0.43: all four clone tests pass with the
passthrough and all four fail without it, so the leg is a real guard.
One representative Python (3.12) via `matrix.include` rather than a
third full column — the flag forwarding it exercises is not
version-specific, so this adds one leg, not five. Installed in the leg
rather than declared, so the runtime floor stays at 0.0.42 and the
effective LangGraph floor stays at >=0.3.25 for consumers.
Also corrects the `test_agui_agent_clone.py` module docstring, which
claimed CI exercised 0.0.42 and 0.0.43 while the workflow installed
0.0.42 and 0.0.44.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Review feedback from contextablemark on #6592.
- Restores the ag-ui-langgraph >=0.0.42 runtime floor and reverts the poetry
lockfile. Raising the floor to 0.0.43 for test coverage alone would also have
raised the effective LangGraph floor from >=0.3.25 to >=0.6.0 for every
consumer, which is a real cost for no user-facing benefit.
- Covers 0.0.42 and 0.0.44 in the python-sdk CI matrix instead, pinned after the
lock resolve so the declared floor is untouched and only the installed version
varies per leg.
- Drops the tests coupled to upstream specifics: the enumerated forwarded-flag
list, the base-__init__ spy, and the unknown-kwarg test that asserted on the
TypeError message text and the raising traceback frame. What remains is
behavior the subclass owns: cloning succeeds, the copilotkit schema namespace
survives, per-request state is isolated in both directions, and a non-default
upstream option survives the clone (guarded, since the floor predates it).
The passthrough itself and the test-helper fix are unchanged.
## Problem
The telemetry fragment workflows regenerate the canonical registry by
running, in the nested `p2p` checkout:
```
pnpm --ignore-workspace install --frozen-lockfile
pnpm --ignore-workspace run reconcile # -> ts-node telemetry-registry/reconcile/index.ts
```
If that install does not put the registry's own dependencies in place,
`reconcile` does not say so. It fails as a cascade of TypeScript errors
pointing at the registry's source:
```
error TS2307: Cannot find module 'node:fs' or its corresponding type declarations.
error TS2307: Cannot find module 'node:path' or its corresponding type declarations.
error TS2304: Cannot find name 'structuredClone'.
error TS2304: Cannot find name '__dirname'.
```
That reads as a bug in oss-path-to-production. It isn't — it's a failed
install. Three `telemetry-docs-fragment` runs failed exactly this way on
2026-08-28 (e.g. run `33216460960`) before #6621 fixed the underlying
cause.
## Change
#6621 fixed the *cause* (pnpm was resolving CopilotKit's parent
workspace instead of the registry's lockfile — visible in the log as
`Scope: all 70 workspace projects`). This adds the missing diagnostic so
a *future* recurrence, from any cause, names itself:
```bash
if [ ! -x node_modules/.bin/ts-node ]; then
echo "::error::Registry dependencies were not installed in p2p/node_modules — check the pnpm install step above."
exit 1
fi
```
Applied to both `telemetry-docs-fragment.yml` and
`telemetry-runtime-fragment.yml`. No behavior change on the success
path.
`ts-node` is the right thing to probe: it is the binary `reconcile`
invokes, and the registry declares it (`ts-node: ^10.9.2`).
## Testing
**1. YAML parses, guard is wired into the intended step**
```
telemetry-docs-fragment: OK, 10 steps, guard present in 1 step(s)
telemetry-runtime-fragment: OK, 10 steps, guard present in 1 step(s)
```
**2. Guard fires when ts-node is absent** (empty dir, no `node_modules`)
```
::error::Registry dependencies were not installed in p2p/node_modules — check the pnpm install step above.
exit=1
```
**3. Guard passes through when ts-node is present**
(`node_modules/.bin/ts-node`, executable)
```
guard passed — would run reconcile
exit=0
```
**4. Probe target confirmed against the real registry checkout**
```
reconcile script: ts-node telemetry-registry/reconcile/index.ts
ts-node declared: ^10.9.2
ts-node present in this checkout's node_modules: yes
```
**5. Formatting**
```
oxfmt --check ... -> All matched files use the correct format.
```
Not provable locally: the workflows themselves only run on their
schedule/dispatch against a real cross-repo token, so the first
end-to-end exercise is their next scheduled run.
## Credit
The guard is lifted from **onsclom's #6435**, which I closed as
otherwise superseded — its telemetry half by #6621 and its
Inspector-flake half by `669132d731`. This piece was the part neither of
those carries.
## Problem
`useAgentNodeName` must update React consumers when AG-UI node events
arrive, and `useLangGraphInterrupt.enabled()` must receive the node
where an interrupt actually occurred.
Current `main` includes the basic ref-to-state reactivity fix from
[ffd1580](https://github.com/CopilotKit/CopilotKit/commit/ffd15801d6d),
but that commit explicitly leaves #1426 open: a later `RUN_FINISHED` can
still replace the interrupting node with `"end"`, and v1 consumers can
still be hidden behind `useCoAgent`'s memoized return value.
## What remains in this PR
Rebased onto current `main` (`e9387e0`) after the v1 source migration,
this PR contains only the remaining behavior:
- Preserve the last active node when `RUN_FINISHED` reports `outcome:
"interrupt"`.
- Preserve it for the legacy `on_interrupt` custom-event flow as well.
- Continue transitioning successful and failed runs to `"end"`; reset
new runs and agent switches to `"start"`.
- Add `nodeName` to the `useCoAgent` return-value memo dependencies so
v1 consumers receive the reactive update.
- Share `INTERRUPT_EVENT_NAME` between the hook and interrupt
implementation.
The public hook signatures and AG-UI protocol remain unchanged.
## Preview workflow
- Disabled pkg-pr-new's generated all-package StackBlitz template;
package preview install URLs remain available.
## Changes
- `packages/react-core/src/v1-deprecated/hooks/use-agent-nodename.ts`
- `packages/react-core/src/v1-deprecated/hooks/use-coagent.ts`
-
`packages/react-core/src/v1-deprecated/hooks/__tests__/use-agent-nodename.test.tsx`
- `packages/react-core/src/v2/types/interrupt.ts`
- `packages/react-core/src/v2/hooks/use-interrupt.tsx`
- `.github/workflows/publish-commit.yml`
## Verification
- Full React Core Vitest suite: **131 files, 1520 tests passed**.
- Preview workflow: Nx formatting and YAML parsing passed.
- `nx run @copilotkit/react-core:check-types --skipNxCache`: passed,
including all 33 dependency tasks.
- `git diff --check origin/main...HEAD`: passed.
- The composite React Core test target then reaches the existing
Windows-only script baseline: 8 path-normalization failures plus 2
symlink-permission failures. These are outside this PR's files; the
complete Vitest suite passes before that script stage.
## Scope
This intentionally does not change the AG-UI event protocol, runtime
event ordering, HITL workflow, v1/v2 compatibility layer, or the
separate node tracking in `use-coagent-state-render-bridge.tsx`.
Fixes#1426
The p2p reconcile step runs `ts-node telemetry-registry/reconcile/index.ts`.
When the registry's own dependencies are missing, that surfaces as a cascade
of TS2307/TS2304 errors against the registry's source -- `Cannot find module
'node:fs'`, `Cannot find name '__dirname'` -- which reads as a bug in the
registry rather than a failed install. Three telemetry-docs-fragment runs
failed that way on 2026-08-28 before #6621 fixed the underlying cause.
Probe for the binary the script actually invokes and fail with a message
naming the install step, so a future recurrence is legible at a glance.
Guard lifted from onsclom's #6435, which is otherwise superseded by #6621
and 669132d731.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
renovate[bot]