@copilotkit/channels is a devDependency and a pure re-export of
@copilotkit/channels-core, so tsdown treated it as bundleable and inlined its
prebuilt declarations into dist/channels/dist/index.d.cts -- along with a
rolldown helper chunk that ships JavaScript only. Consumers got a TS7016 for a
file they cannot see.
channels-core is a real dependency and stays external, so importing the types
from there drops the inlined copy entirely.
GraphQLContext was defined as `YogaInitialContext & {...}`. That single type
reference pulled the whole graphql-yoga barrel into every consumer's program,
and with it lru-cache@10, whose `implements Map` clause costs five TS2416
errors under strict + skipLibCheck: false.
Nothing in this package serves GraphQL any more -- every v1 integration entry
point delegates to the v2 Hono endpoint -- so the type is declared locally
instead. It is structurally identical, so a real Yoga context still satisfies it.
OSS-899 shipped 81 strict-mode errors to consumers because nothing checked what
the published .d.cts files reach for. validate-dts-ambient.ts checks their shape;
this checks their imports against the one thing that matters -- whether someone
who installed this package and nothing else can resolve them.
Flags devDependencies, optional peers, dependencies whose types live in a
devDependency @types package, relative imports of JS-only bundler chunks, and an
explicit ban on graphql-yoga, whose types drag lru-cache@10 into every consumer
program. Currently red on 18 real violations; the fixes follow.
The landing card ended in "The failed run event is highlighted below."
unconditionally, but the error carries no guarantee that such an item
exists. A code that reaches `run` through the catch-all without a run of
its own -- a locked thread, an agent that was never registered -- lands on
an empty AG-UI Events with the card still pointing at nothing, and
`applyEventErrorLanding` bails out silently rather than telling it. Same
for a tool error that arrives without a call id.
Split the copy by what it can promise: `advice` is about the reader's next
move and always holds, `highlight` is a claim about this view and renders
only once the item is there. Sending someone to look for something absent
is worse than saying nothing.
The mapping itself is unchanged. Whether a locked thread should be called
a failed run at all is a separate question for its author.
The comment sat above the langgraph/langchain pins but read as a claim that the
whole dependency set tracks examples/integrations/langgraph-python. It does not —
copilotkit and ag-ui-protocol are both behind that example. Say which pair the
statement covers.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The Usage section documented a frontend deploy that could not work after a
`terraform apply`. Three defects compounded:
- The bash block ran `cd infra-terraform` and never returned, then the prose
claimed the next command ran "from the repo root" — stated cwd and actual
cwd disagreed.
- There are two `deploy-frontend.py` files. The example-root one is the CDK
variant: it reads stack outputs via `aws cloudformation describe-stacks`.
The Terraform deployment's outputs live in `terraform output -json`, which
only `infra-terraform/scripts/deploy-frontend.py` reads. Followed literally
from the repo/example root, `uv run scripts/deploy-frontend.py` executed the
CDK script.
- The CDK script also requires a stack-name argument (`sys.argv[1]`, or
`STACK_NAME`, or `infra-cdk/config.yaml` — which does not exist in this
example), and the documented invocation passed none. The deploy shell
scripts do pass it; the README did not.
The command is now `uv run --project .. scripts/deploy-frontend.py`, run from
`infra-terraform/`. `--project ..` resolves the example-root `pyproject.toml`
that owns the tooling dependencies, matching the convention already used in
`infra-terraform/scripts/test-agent.py`. The starting cwd for the whole
section is now stated, and the optional `--pattern` override (the only
argument this script accepts) is documented.
Verification, from `examples/integrations/agentcore/`:
# uv resolves the example-root project and does not change cwd
$ cd infra-terraform && uv run --project .. python -c "import os,sys; \
print(os.getcwd()); print(sys.prefix)"
.../agentcore/infra-terraform
.../agentcore/.venv
# which file each command actually executes (path + sha256 printed by a
# sitecustomize probe that exits before the script body — no AWS calls)
old, from example root: .../agentcore/scripts/deploy-frontend.py
sha256 1c3ed4f2… "…script for FAST." (CDK)
new, from infra-terraform: .../infra-terraform/scripts/deploy-frontend.py
sha256 16d3bc3c… "…for Terraform deployments."
# argument signature, real runs (terraform binary absent here, so the run
# stops at the prerequisite check before any AWS call)
$ uv run --project .. scripts/deploy-frontend.py -> exit 1, "terraform is not installed"
$ uv run --project .. scripts/deploy-frontend.py --pattern langgraph-single-agent
-> exit 1, same prereq stop
$ uv run --project .. scripts/deploy-frontend.py some-stack-name
-> exit 2, "unrecognized arguments"
The last case confirms the stack-name positional belongs to the CDK script
only. `--help` on the resolved script prints "Deploy frontend to AWS Amplify
using Terraform outputs". No AWS credentials were used and no AWS API was
called.
The known `aws_region` variable issue and the missing teardown section are
tracked separately and are untouched.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
start_local_agent() launched the agent with stdout=PIPE and stderr=PIPE and
then never read either pipe. The child blocks the moment it fills a ~64KB
pipe buffer, so a chatty agent wedges before it can bind port 8080. Worse,
the 30-second startup-timeout branch called _agent_process.stderr.read() --
a blocking read to EOF -- on a child that was still alive, so the tester hung
forever instead of reporting the timeout.
This mattered more since the command became `uv run --locked --project ...`:
uv writes resolution and install progress to stderr before the agent starts,
and the message uv prints when uv.lock has drifted from pyproject.toml only
reached the developer through that same wedged branch.
Fix: do not pipe the child at all. stdout/stderr are inherited, so agent logs
and uv's errors stream straight to the developer's terminal (this is an
interactive tool), the child can never block on a full pipe, and no reader
threads are needed. The wait loop now also polls the child each second and
fails fast with its exit code when it dies early, instead of burning the full
30 seconds. The timeout branch delegates cleanup to stop_local_agent(), which
is now idempotent (clears the global first) so the timeout path, the SIGINT
handler and the atexit hook cannot double-stop or double-print, and kill() is
followed by wait() so the process is reaped.
Verification (standalone reproductions; this file has no test suite):
- Old code vs a child writing 8000 lines and staying alive: the child never
finished writing (deadlocked on a full pipe) and the parent hung in
stderr.read() until an external timeout killed it (exit 124).
- New code, real start_local_agent() driven against the same child: the child
wrote all 8000 lines, the parent hit its timeout, stopped the agent and
exited 1 after 30.1s.
- Real uv project with a stale uv.lock: the developer sees
"error: The lockfile at `uv.lock` needs to be updated, but `--locked` was
provided." live on the terminal, and the tester reports
"Agent exited with code 2 before port 8080 opened" after 1.0s.
- python3 -m py_compile passes.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Several packages that agentcore code imports at module scope were never
declared in the pyproject.toml of the project that ships them. They only
resolved because something else happened to pull them in, so the next
`uv lock` that drops the intermediate would silently remove them.
That is newly dangerous: both agent Dockerfiles now install with
`uv sync --locked`, so the installed set is exactly the lockfile rather
than whatever pip incidentally resolved. A dropped transitive would turn
into an ImportError at container start instead of a quiet near-miss.
Undeclared but directly imported:
- boto3 — `agents/utils/ssm.py:12`. `agents/utils/` is COPY'd into BOTH
agent images, so both agent projects need it; neither declared it.
- PyJWT — `agents/utils/auth.py:11`. strands declared it, langgraph did
not and resolved it transitively only. langgraph now matches strands
(`PyJWT[crypto]>=2.10.1`) since it is the same shared module.
- langchain-core — `tools/todos.py:10` imports `langchain_core.messages`
in the langgraph agent; it rode in on `langchain`.
- botocore — `scripts/utils.py:17` imports `botocore.exceptions`; the
example-root project declared boto3 but not botocore.
Floors are set at or below what the existing lockfiles already resolve,
so nothing is bumped. The lock diffs are additive metadata only: zero
resolved versions changed and no new packages entered any lock.
Deliberately not declared: `docker/resolve-env.py` (boto3, PyYAML) is
already covered by the root project; `infra-cdk/lambdas/oauth2-provider/`
uses boto3 from the Lambda runtime and is bundled by CDK, not by any of
these three uv projects.
Verification (run, not read):
$ docker build --platform linux/arm64 \
-f agents/langgraph-single-agent/Dockerfile -t acuv-lg-a2:test .
naming to docker.io/library/acuv-lg-a2:test done
$ docker build --platform linux/arm64 \
-f agents/strands-single-agent/Dockerfile -t acuv-st-a2:test .
naming to docker.io/library/acuv-st-a2:test done
$ docker run --rm --platform linux/arm64 \
-e GATEWAY_CREDENTIAL_PROVIDER_NAME=dummy -e AWS_DEFAULT_REGION=us-east-1 \
acuv-lg-a2:test sh -c 'python -c "import langgraph_agent, boto3, jwt, langchain_core, utils.ssm, utils.auth, tools; ..."'
OK lg 1.43.78 2.13.0 1.6.0
$ docker run --rm --platform linux/arm64 ... acuv-st-a2:test \
sh -c 'python -c "import strands_agent, boto3, jwt, utils.ssm, utils.auth, tools; ..."'
OK st 1.43.78 2.13.0
$ uv run --locked scripts/test-agent.py --help # exit 0, usage printed
$ uv lock --check # passes for all three projects (14 / 144 / 123 packages)
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
terraform_data.docker_image_hash hashed every `**/*.py` under
`local.pattern_dir`. Since the example moved to per-agent uv projects,
that directory grows a `.venv/` the moment a developer runs `uv sync` or
the local agent tester, and the virtualenv's dependency sources were
being folded into the hash.
That hash feeds null_resource.docker_build_push.triggers and the
runtime's replace_triggered_by, so a developer who has ever run the
agent locally got a spurious image rebuild plus a forced AgentCore
runtime replacement, and two developers produced different plans from
identical committed sources. The virtualenv never reaches the image
anyway — .dockerignore excludes `**/.venv/` — so it must not reach the
image hash either.
fileset() has no exclude argument, so both comprehensions (pattern dir
and shared utils dir) now filter on local.venv_path_regex,
`(^|/)\.?venv/`, which drops `.venv/` and `venv/` at any depth while
keeping files that merely start or end with those characters
(`tools/venv_helpers.py`, `myvenv/x.py`).
Verified by measurement, not by reading — Terraform is not installed, so
the expression was reproduced exactly (fileset `**/*.py` including
dot-directories, lexicographic set order, sha256 over the joined
filesha256 digests) and evaluated against two worktrees holding
byte-identical agent sources, one with a real 167 MB `.venv` present and
one without:
OLD with .venv: fileset 3114, hashed 3114 -> 5f9a98ef...
OLD without: fileset 5, hashed 5 -> bacab1e1... (DIFFER)
NEW with .venv: fileset 3114, hashed 5 -> bacab1e1...
NEW without: fileset 5, hashed 5 -> bacab1e1... (IDENTICAL)
The two OLD digests reproduce the reported values exactly, and the NEW
value equals the clean-checkout digest, so the fix introduces no new
hash and therefore no replacement for existing state. All 3109 dropped
paths were under `.venv/`; the 5 kept are the real agent sources. A
synthetic fixture additionally confirmed the shared-utils comprehension
and the non-dot `venv/` (UV_PROJECT_ENVIRONMENT) variant are covered.
Audit: these were the only fileset/filesha256 expressions in runtime.tf.
The known undeclared-resource references in this file are untouched.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Resolves conflicts in the two custom-agent docs copies. Main's "docs: update
Anthropic model references to Opus 4.8" (518feae6cd) independently bumped the
Anthropic thinking snippets to `claude-sonnet-4-6` -- the same model id this
branch picked -- so the overlap was textual, not a disagreement.
Kept this branch's side in both files: it already carries that model id and
additionally moves the AI SDK options into `providerOptions.anthropic` and
switches to `{ type: "adaptive" }` with `effort`. Main's bumps on the
surrounding property-forwarding examples merge in unchanged.
Two type errors the example could not see. It has no check-types target,
and the import is type-only, so esbuild erases it and the build passes.
- `CopilotKitCoreFriendsAccess` came from `@copilotkit/core`, which the
example does not depend on. `react-core/v2` re-exports it.
- `onError` also accepts React's DOM error handler, so the parameter is a
union and reading `.error` / `.context` off it is not allowed. Narrow on
the CopilotKit shape first; a synthetic DOM event has nothing to report.
Example type errors go from 9 to 3. The three left are older: two react
-router codegen paths and one model name.
The thread-list-error route asserts that the first open lands on Threads
rather than Home. That only holds once the list request has been refused,
and the request is still in flight at that point: the helper waits two
microtask turns and a render, never the fetch. On a loaded machine the
fetch loses the race, the launcher carries no signal yet, and the open
lands on Home.
Green locally, red on all six CI matrix combinations. Reproduced here by
delaying the list fetch, which fails the assertion at 300ms and passes it
with this change at 1200ms.
Prerequisites listed "Python 3.8+", which no longer matches anything: the agents
require 3.13 and uv provisions the interpreter, so uv is the only thing a reader
needs to install. Adds a short section on where dependencies live and the
obligation to commit uv.lock, and updates the Terraform README's frontend deploy
command to match.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The Terraform docker-mode image hash read `patterns/<pattern>/requirements.txt`,
`patterns/utils`, a root-level `gateway/` and `tools/`, and a root `pyproject.toml`
— none of which exist in this example. `filesha256` on a missing file is a plan-time
error, so docker mode could not plan at all, and the same `patterns/` prefix was
baked into the build command and the standalone build-and-push script.
Point them at `agents/<pattern>` and `agents/utils`, and hash the agent's
`pyproject.toml` and `uv.lock` now that the dependency set is locked, so a
dependency bump retriggers the image build.
Zip mode is left alone; it references a `basic_agent.py` entry point and a
`lambdas/zip-packager` directory that are also absent, which is a separate
problem from the uv conversion.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The deploy and local-dev scripts called bare `python3` and relied on the caller
already having PyYAML, requests, boto3 and colorama importable. `scripts/requirements.txt`
listed them but nothing installed it, and `uv run scripts/test-agent.py` — the
command the script's own docstring gives — failed because there was no project
for uv to resolve against.
Route every Python entry point through `uv run --project`, backed by the
example-root project added in the previous commit, and drop the orphaned
`requirements.txt`. Preflight now checks for `uv` rather than `python3`; uv
provisions the interpreter itself, so the hand-rolled Python 3.8 version assert
goes away with it.
`test-agent.py` starts a local agent inside that agent's own uv project with
`--locked`, so a locally run agent gets the same dependency set as its image
instead of an ad-hoc resolve.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Both AgentCore agents installed from an unlocked `requirements.txt`, so every
image build re-resolved transitive dependencies from scratch. That had already
drifted into a broken state: `langgraph==1.0.10rc1` pulled in a langgraph-prebuilt
that reads `ExecutionInfo` off `langgraph.runtime`, which 1.0.x does not export,
so `import langgraph_agent` failed at container start.
Give each agent a `pyproject.toml` + `uv.lock` and install with `uv sync --locked`,
matching how every other Python integration example is set up. Bump langgraph to
1.1.6 and pin langchain to 1.2.15 — the pair used by
examples/integrations/langgraph-python — to resolve the import failure, and fold
the separately installed `aws-opentelemetry-distro` into the locked dependency
set so it is pinned too.
The example root also gains a `pyproject.toml` + `uv.lock` for the `scripts/`
helpers, whose dependencies were previously declared in a `requirements.txt`
that nothing installed.
Verified by building both images for linux/arm64 and importing the agent module
inside each container.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Twelve quickstarts provisioned a license key in step 1 and then showed a
runtime constructed with `runner: new InMemoryAgentRunner()` — an option
that is mutually exclusive with `intelligence`, so the key was never read.
Threads showed "locked" and nothing indicated a choice had been made.
Each of those pages now constructs the runtime with `intelligence` and
`identifyUser`, names `INTELLIGENCE_API_KEY` where the route reads it, and
links /premium/connect-your-runtime — which had no inbound link from any
quickstart. The in-memory runner stays available as a labelled opt-out;
it was already the default, so passing it explicitly only added the steer.
Also adds the required `name` field to the `identifyUser` snippets in
connect-your-runtime.mdx and the runtime skill's agent-runners reference.
Both omitted it, so copying either was a type error.
Scope is every page that provisions a key and then shows a runtime that
cannot consume it. Pages that legitimately document the in-memory runner
(backend/agent-runner, deploy/agentcore) are unchanged.
Verified: all 15 doctest `component` snippets typecheck against the pinned
@copilotkit/runtime@1.68.3, and the gate goes red when `name` is removed.
Click the red Inspector launcher after a run or a tool fails. Inspector
opens the pane that explains that error and highlights the failed item.
## What does this PR do?
The launcher already turns red for CopilotKit errors (see #6656). This
PR takes the click to the explaining view:
- Tool handler / missing tool: Agent pane. The banner names the agent,
the tool, and the error. The failed tool card is highlighted.
- Agent run / `RUN_ERROR`: AG-UI Events. The banner names the agent and
the error. The `RUN_ERROR` event is highlighted and expanded.
- Click the in-panel banner again. Inspector returns to that same item.
The beat before the error pill is 400ms (was 1500ms). Failed tool titles
use dark text on a light rose card so "crash failed" stays readable.
The react-router example can produce these errors in chat:
- `crash the tool` calls a real `crash` frontend tool that throws.
- `crash the run` makes the server emit `RUN_ERROR` after `RUN_STARTED`.
Refresh no longer keeps a fake Threads 503 from the Break threads
cookie.
## Related PRs and Issues
- Stacked on #6656 (`lukas/oss-903-error-pill`)
- Follows #6646
- Linear:
[OSS-903](https://linear.app/copilotkit/issue/OSS-903/presentation-wire-errors-notifications-to-emanate-from-and-open-the)
## Checklist
- [ ] I have read the [Contribution
Guide](https://github.com/copilotkit/copilotkit/blob/master/CONTRIBUTING.md)
- [x] If the PR changes or adds functionality, I have updated the
relevant documentation
- [x] "Allow edits by maintainers" is checked (lets us help iterate on
your PR directly — faster turnaround for everyone)
## Testing
**Commands run**
1. `pnpm nx test web-inspector` — 26/26 passed on the inspector commit.
2. Example/docs commit ran lefthook (lint, lockfile sync, env-name
check). Passed.
3. `pnpm install --frozen-lockfile --ignore-scripts` — passed after the
lockfile specifier fix.
4. I did not run `pnpm test:pr`.
**Manual test**
1. Run `pnpm --filter react-router-example dev`. Open
http://localhost:5173/.
2. Send `crash the tool`. Click the red launcher. Agent pane must show
the failed `crash` tool, not "No agent selected".
3. Send `crash the run`. Click the red launcher. AG-UI Events must
highlight `RUN_ERROR`.
4. Click Break threads, then refresh. Threads must load. Do not keep
"Failed to load threads."
**How this PR makes testing easy**
`packages/web-inspector/src/__tests__/launcher-error-signal.spec.ts`
covers landing. `examples/v2/react-router` is a live lab for the same
paths.
## Risk / rollback
Inspector click-to-pane behavior changes for run and tool errors. Revert
this PR to restore the previous landing. The example lab is local-only.
`CopilotIntelligenceRuntime` hardcodes `IntelligenceAgentRunner` into its
`super()` call, so a caller-supplied `runner` could never be honored. The type
forbids it — `runner` is declared only on `CopilotSseRuntimeOptions` — but that
is an excess-property check: a JS, `as any`, or non-literal caller passing
`{ intelligence, runner }` reached the constructor and had `runner` silently
dropped with no diagnostic.
Add the runtime guard, mirroring the `channels` guard already in
`CopilotSseRuntime` for exactly this reason. Explicit `runner: undefined` still
constructs, matching how the sibling `identifyUser` / `channels` / `memory`
guards treat undefined.
This also resolves a contradiction inside the shipped runtime skill:
`SKILL.md:87` already asserted the rejection happens at construction, while
`references/agent-runners.md` correctly described the silent drop. The guard
makes SKILL.md true; agent-runners.md is updated to describe the throw and to
cite line numbers that match the current file.
Add chat phrases and lab buttons that fail a frontend tool or emit RUN_ERROR.
Clear the Break threads cookie on load so a refresh does not keep a fake
thread-list failure.
Show agent, tool, and error on Inspector banners. Click the launcher to open the failed tool call or RUN_ERROR. Shorten the error pill wait to 400ms. Use dark gray titles on the rose tool-error card so the name stays readable.
Self-review of the previous commit found three defects, two of them factual
errors I asserted without checking.
1. The promise form can kill the process. I documented
`agents: MastraAgent.getRemoteAgents({ ... })` and described its failure mode
as "the rejection is cached and every later request fails". That understated
it: the call starts at module load with nothing awaiting it, so an agent
server that is not up yet produces an *unhandled* rejection and Node
terminates. Both files now lead with the factory form, which has no such
window — nothing runs until a request arrives, a failure is a 500, and the
next request retries.
2. The tsconfig warning named the wrong key. `next dev` does not overwrite
`moduleResolution: "NodeNext"` — `nodenext` is in Next's accepted set for
both `module` and `moduleResolution`. What it actually does at its own root
is force `esModuleInterop`, `isolatedModules`, `resolveJsonModule` and `jsx`,
set `noEmit: true`, and replace `include`/`exclude`. `noEmit` is the sharp
one for an agent project that compiles with `tsc`. The advice stands; the
mechanism is now the verified one.
3. `MASTRA_BASE_URL` was set in the wrong shell. It was exported in the agent's
terminal, where the frontend cannot see it. It now appears as `.env.local` in
the Next app, next to the route that reads it. The port note moved to the
step that starts the agent, and says what `mastra dev` really does: 4111 when
free, walking up to 4131 when not.
Verified:
shipped fence, agent down -> up -> 500, then 200; process survived, no restart
promise form, agent down -> node terminated on unhandled rejection
next build, NodeNext tsconfig -> 13 keys written; module/moduleResolution untouched
mastra CLI -> serverPort 4111, getPort over 4111..4131, apiPrefix /api
extracted fence, runner config -> tsc exit 0; mutation (drop resourceId) -> TS2741
MDX compile, both files -> OK
The behavioural checks drove the extracted fence itself, not a paraphrase of it.
Refs OSS-925.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
## Summary
- enable the LlamaIndex multimodal Showcase demo
- update the LlamaIndex AG-UI protocol pin and its compatible
core/OpenAI adapter pins
- register the multimodal agent and refresh the integration parity notes
## Verification
- Showcase manifest and route validation passed
- LlamaIndex integration production build passed
- container dependency check passed with core 0.14.24, llms-openai
0.7.10, and protocols-ag-ui 0.4.1
- live local OpenAI smoke passed for both image and PDF attachments
## Known harness issue
The shared D6 image assertion still expects the exact contiguous phrase
`copilotkit logo`; OpenAI returned the semantically equivalent `a logo
for CopilotKit`. The browser validation confirmed one intact image
attachment and a relevant response.
## What
Eleven demos in the `crewai-crews` showcase column (labelled **CrewAI
Flows** in the UI) were served by `add_crewai_crew_fastapi_endpoint`
through a root catch-all, not by the Flow helper. This moves them onto a
real CrewAI Flow and removes the catch-all.
Affected demos: agentic-chat, gen-ui-tool-based, prebuilt-sidebar,
prebuilt-popup, chat-slots, chat-customization-css, headless-simple,
readonly-state-agent-context, agent-config, auth, voice.
## Why
`add_crewai_crew_fastapi_endpoint` wraps the crew in `ChatWithCrewFlow`,
which composes its system message with CrewAI's `build_system_message`.
That boilerplate is unconditional: it instructs the model to introduce
itself and to steer every answer back to the crew's purpose, using a
research-report example. Because the catch-all served the scaffold
research crew, those demos answered the user's question and then offered
to research the latest AI developments.
Measured against real OpenAI on `main`, first turn:
> Hey! I'm here to help you with researching cutting-edge developments
and producing detailed, actionable reports.
> The capital of France is **Paris**. If you'd like, I can also help by
generating a **current research report** on a topic of your choice.
Second turn, arithmetic question:
> 12 × 12 = 144.
> I'm here to help with researching the latest AI developments and
producing actionable reports.
Pre-seeding a hand-written `crew_description` (the existing
`_chat_flow_helpers.preseed_system_prompt`) only retargets that tail, it
does not remove it — verified on `/mcp-apps`, which is pre-seeded and
still introduces itself and offers a diagram.
## How
- New `src/agents/chat_flow.py` holds `PromptedChatFlow`, a one-turn
Flow that owns its own prompt and forwards frontend tools.
`crewai-conversational-flows` already had this class inline; it now
imports the same file, so both columns share one prompt.
- `agent_server.py` registers it at `/chat` via
`add_crewai_flow_fastapi_endpoint`, and the root catch-all registration
is gone. An unrouted agent name now fails loudly instead of landing on
someone else's backend.
- The runtime route's default target becomes `/chat`; the
`agent-config`, `auth`, and `voice` routes point there too.
- The remaining crew endpoints (`/mcp-apps`, `/byoc-hashbrown`,
`/byoc-json-render`) are untouched — each already overrides the composed
system message explicitly.
- Comments that described the removed catch-all were corrected in both
CrewAI columns.
## Verification
Against real OpenAI on the patched backend:
- `/chat` answers `Paris.` and `12 × 12 = 144.` with no purpose-reminder
tail.
- A frontend tool still round-trips: `generate_haiku` emits
`TOOL_CALL_START` / `TOOL_CALL_ARGS` / `TOOL_CALL_END`.
- `POST /` returns 404.
Python suites: 162 passed (`crewai-crews`), 164 passed
(`crewai-conversational-flows`). New coverage in `test_chat_flow.py`
(prompt contract, no crew-chat boilerplate, tool forwarding) plus a
routing contract test asserting no cell can reach a crew endpoint by
fall-through.
D6 replay: see the checklist below.
### D6 replay (local, `--d6 --direct`, warm stack)
All fourteen green: the eleven affected cells (agentic-chat,
gen-ui-tool-based, prebuilt-sidebar, prebuilt-popup, chat-slots,
chat-customization-css, headless-simple, readonly-state-agent-context,
agent-config, auth, voice) plus tool-rendering, hitl-in-chat and
shared-state-read-write as untouched controls.
gen-ui-tool-based needed the second commit: the shared probe had both
CrewAI columns off its chart-integration list, so it sent the haiku
prompt and waited for a haiku card the page cannot draw. The probe's own
unit tests still pass (11).
The conversational column's D6 was not run — it is not deployed, and its
image was not built in this session. Its Python suite passes and its
wiring mirrors the crews column line for line.
`MastraAgent.getRemoteAgents` appeared nowhere in this repo — not in
shell-docs, not in an example. The only wiring the Mastra quickstart taught was
`getLocalAgents({ mastra })` behind `import { mastra } from "@/mastra"`,
including on the "Use an existing agent" branch, which two steps earlier tells
you to `create-next-app` a *separate* directory. That import cannot resolve, and
the shape it teaches moves a running Mastra service into the frontend, deleting
the process the reader was trying to keep.
All four cells of the 2026-08-21 Mastra x Next.js sweep reached the agent over
HTTP, and all four derived how on their own; `both` filed it as its largest
friction and `empty` as its worst papercut at ~10 minutes.
- Quickstart, existing-agent branch: wire the route with `getRemoteAgents` over
a `MastraClient`, add the `MASTRA_BASE_URL` convention, and add the missing
step that starts the agent server. `/api/agents` is the liveness check; a
bare `GET /` answers 200 from Mastra's console whether an agent is registered
or not.
- Warn that `next dev` rewrites the `tsconfig.json` at its own root, so the
frontend belongs in a sibling package — the reason this path goes over HTTP.
- copilot-runtime.mdx: a "Local vs remote agents" section that decides between
them by where the agent runs, with the full `GetRemoteAgentsOptions` contract,
the promise-vs-factory trade-off, and the local-only options
(`requestContext`, `untilIdle`).
- Gate the new route fence in CI (`doctest="component"` plus a mastra
`doctest.json`). The old fence could never have been gated: `@/mastra` does
not resolve. Mastra now has its first typechecked route snippet.
Verified:
MDX compile, both files -> OK (mutation-checked: unclosed tag -> FAIL)
doc-test extraction -> 21 -> 22 fences; mastra sidecar selected
extracted fence, runner config -> tsc exit 0 (runtime 1.68.3; ag-ui/mastra 1.1.1, 1.1.2)
mutation: drop resourceId -> tsc exit 1, TS2741
previously documented shape -> tsc exit 2, resourceId missing
validate-intelligence-env-names -> exit 0
Not run: the shell-docs vitest suite. No test reads either file and no page was
added or moved, so nav, sitemap and llms.txt are unchanged.
Refs OSS-925.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Five changes from looking at rendered variants side by side, none of them
behavioural.
The reveal animates a rounded clip. Without a round component the
revealing edge is a straight line sweeping sideways, which reads as a
wipe; with it the edge is the capsule's own cap travelling outward.
The text side of the padding is derived from the capsule's radius rather
than being a literal. Padding is measured from the bounding box, but the
first half-height of that side is the rounded cap, so a bare 14px left
the words sitting inside the curve — and the launcher size is itself a
clamp on the viewport, so no literal could have been right at every size.
The label is two lines now, a heading and a subline, at 12px and 10.5px.
It stays exactly as tall as the launcher; there was room above and below.
The pill takes pointer events while it is on screen, so a click opens the
Inspector as pressing the launcher does. That makes the subline's
instruction honest. It is deliberately not focusable: the launcher is
already a focusable control for the same action, and a second tab stop
for one action would be a regression.
The launcher's surface and edge are now two custom properties declared
once on the wrapper and resolved by both the button and the pill, so the
two cannot drift apart. The pill's own red-tinted border is gone — it read
as a second object rather than as the launcher opening. The surface moves
from near-black to a dark grey, softening the edge against a white page
from 20.5:1 to 16.5:1 while staying far above any legibility threshold.
Refs OSS-903
Once per outage the launcher beats, then opens sideways into a short pill
carrying the failure's name, holds long enough to read, and closes back to
the plain mark. Nothing stays behind: the dot keeps the state, the pill
carries only the moment.
The ticket this belongs to started with a user who could not tell what the
button was. A dot says something is wrong without saying who is asking, so
the pill names both the problem and the control raising it.
Errors only. The announcement feed's preview text is 54 characters against
a 36px launcher, so a pill carrying it would be ten times the width of the
control it grows from, sized by a feed we do not control. The label is read
from the signal rather than keyed off the tone, so a third signal can carry
one by declaring it.
The reveal animates a rectangular clip. Animating width would recompute
layout on every frame of someone else's page; scaling horizontally squashes
the mark itself, not merely the rounded ends. The contract is therefore
restated rather than broken: the rule was never "opacity and transform", it
is that nothing may force a layout per frame.
Direction comes from available room, because the launcher can be dragged to
within a margin of the left edge and that position persists. Left if it
fits, otherwise right, otherwise no pill at all -- the dot and the beat
still fire, so only the label is lost.
Recovery says nothing. The dot going out is already the message, and
announcing it would double the gestures across the break-and-fix cycle that
debugging consists of.
The whole gesture holds the single pending-beat slot, so an announcement
beat waits rather than cutting into it. Reduced motion gets the same words
and the same reading time without the movement. A polite live region speaks
the failure once, so the pill is not a sighted-only feature.
Refs OSS-903
## Summary
- The v1 SDK is deprecated. Use v2 instead.
- Mark every public/importable v1 SDK export with an IDE-visible
`@deprecated` warning: 245 exports across 9 entrypoints and 103 source
files.
- Give each warning a verified v2 import and copyable usage snippet when
an equivalent exists.
- When there is no exact replacement, link to a curated nearby v2
concept when one is genuinely relevant; otherwise fall back honestly to
both the v2 docs homepage and v2 reference instead of inventing a
mapping.
- Put the same “v1 SDK deprecated; use v2 instead” callout and
exhaustive export map in the human-facing v1 reference and
agent-readable docs output.
- Repair stale v1 reference links so LangGraph authentication and state
rendering point to the current live guides.
- Preserve warnings in published declarations so package consumers see
them in IDEs.
- Exclude Vue explicitly: it is newer and does not expose the same
deprecated root-v1/`/v2` package split.
- Require agents to fetch the latest remote `origin/main` before
beginning work in any worktree and to use the fetched merge base for Nx
affected checks.
## Deliberately no file moves
This PR contains **no rename entries**. The filesystem transition was
split into the stacked follow-up
[#6589](https://github.com/CopilotKit/CopilotKit/pull/6589) so reviewers
can evaluate the warnings, mappings, docs, and enforcement without
hundreds of moves obscuring the functional diff.
Review order:
1. This PR: v1 SDK deprecated; use v2 instead — behavior, migration
guidance, docs, and enforcement.
2. [#6589](https://github.com/CopilotKit/CopilotKit/pull/6589): move the
already-deprecated implementation into `v1-deprecated/` and
`v1-deprecated-compatibility.ts`.
## Mapping corrections and related concepts
- The v1 `useRenderToolCall` hook maps to v2 `useRenderTool` for
rendering an existing backend tool. The v2 hook also named
`useRenderToolCall` is a different low-level consumer API.
- The v1 `useCoAgentStateRender` hook maps semantically to v2
`useAgent`: subscribe to state and run-status updates, then render
`agent.state` with ordinary React UI. The generated import-and-usage
snippet links directly to the [v2 state-rendering
guide](https://docs.copilotkit.ai/generative-ui/state-rendering).
- APIs without an exact replacement now use three honest tiers: exact
replacement and snippet; curated related v2 concept; or generic v2 docs
homepage plus v2 reference.
- Curated concepts cover state rendering, tool rendering, tool-based
generative UI, human-in-the-loop, agent context, provider setup, runtime
adapters, chat suggestions, chat UI, conversation threads, MCP, and
LangGraph agents.
- Generic `https://docs.copilotkit.ai/reference/v2` links are labeled
“V2 reference docs”; the general “V2 docs” link is
`https://docs.copilotkit.ai/`.
## Guardrails
- The generated inventory covers every public non-v2 entrypoint in the
packages in scope.
- Every importable v1 export must have the complete IDE warning text.
- Verified replacements must include an exact import, usage snippet,
replacement source, and v2 docs link.
- APIs without a verified 1:1 replacement say so explicitly, include a
curated related concept where available, and always retain the
docs-home/reference/migration fallbacks.
- A regression test forbids labeling the generic v2 reference page as
the general v2 docs page.
- Built `.d.mts` and `.d.cts` outputs are checked for deprecation
metadata.
- Agent-readable docs output is checked for all 245 exports.
- Vue is absent from both the inventory and the diff.
## Validation
- Generator: 245/245 public v1 exports across 9/9 entrypoints and 103
source files
- Deprecation inventory/declaration tests: 16/16 (14 source/inventory +
2 built-declaration tests)
- Package tests: 3,759 passed across React Core, React UI, React
Textarea, Runtime, and SDK JS
- Agent-facing docs tests: 58/58 across LLM text, link rewriting, and
reference discovery
- Typechecks: all five affected SDK projects plus their dependency graph
- Builds: all five affected SDK projects plus their dependency graph
- Shell-docs typecheck and production build: pass; 223/223 static pages
generated
- Scoped lint: 0 errors
- Formatting and `git diff --check` pass
- Every added related-concept destination, the v2 docs homepage, and the
v2 reference return HTTP 200
- Repaired LangGraph authentication and state-rendering routes both
return HTTP 200
- Vue is byte-for-byte unchanged from `origin/main`
- Git rename audit: zero rename entries
## Verified upstream exceptions
- The full shell-docs unit suite has one pre-existing Channels
architecture-image assertion mismatch: 421 tests pass and one test
expects a dark asset while the page intentionally uses the current light
asset in both themes. The failing test and page are byte-identical to
fetched `origin/main`; neither PR touches Channels. Relevant docs tests
and the shell-docs production build pass.
- The full `nx affected` build reaches unrelated downstream examples
with failures reproduced outside this diff, including duplicate
LangChain versions, missing example dependencies/exports, and build-time
environment requirements such as `OPENAI_API_KEY`. Isolated affected
package builds and docs checks pass.
Benjamin Taylor