The v1 <CopilotKit> wrapper's validateProps threw ConfigurationError
whenever neither runtimeUrl nor a public key was supplied, ignoring
self-managed agents. This rejected the documented self-managed-agent
setup even though the underlying v2 CopilotKitProvider accepts it.
Mirror the provider's hasLocalAgents gate so selfManagedAgents and
agents__unsafe_dev_only satisfy the check.
Closes#5417
## Summary
Follow-up to #5543. Adds `--isolate=<N>` CLI form so users don't need to
set `SHOWCASE_ISO_SLOT=<N>` as an env var prefix.
## Before
```
SHOWCASE_ISO_SLOT=9 bin/showcase test agno --d5 --isolate
```
## After (both forms work)
```
bin/showcase test agno --d5 --isolate=9
# OR
SHOWCASE_ISO_SLOT=9 bin/showcase test agno --d5 --isolate
```
## Implementation
~10 lines in `showcase/scripts/cli/cmd-test.sh` arg parser: a new
`--isolate=*` case sets `use_isolate=true` and exports
`SHOWCASE_ISO_SLOT=<N>`. The existing picker (`_claim_isolate_slot` in
`_common.sh`) handles all validation, slot-0 rejection, port-probe,
liveness, etc. — no logic duplication.
Help text in `cmd-test.sh` and the existing `SHOWCASE_ISO_SLOT`
references in `showcase/TESTING.md` now show both forms as equivalent.
## Tests
Four new bats tests in `showcase/scripts/__tests__/isolate.bats`:
- `--isolate=<N> arg form exports SHOWCASE_ISO_SLOT and pins the slot
through the picker` — replays the parser branch, verifies env export +
picker pinning.
- `--isolate=0 arg form drives the picker's reserved-slot rejection` —
proves `--isolate=0` flows through the same `slot 0 is reserved` die as
the env-var form.
- `--isolate=99 arg form drives the picker's out-of-range rejection` —
proves `--isolate=99` flows through the same `exceeds
ISOLATE_MAX_SLOT=45` die as the env-var form.
- `cmd-test.sh --isolate=<N> actually wires the arg through to
SHOWCASE_ISO_SLOT` — drift guard that sources the REAL `cmd-test.sh`,
stubs `apply_isolation`, and snapshots `SHOWCASE_ISO_SLOT` to catch any
future regression of the parser branch.
All 58 bats tests in `isolate.bats` pass locally (54 pre-existing + 4
new).
## Docs
`showcase/TESTING.md` items 8 and 9 updated to show both forms.
Repo-wide grep confirmed TESTING.md is the only doc that references
`SHOWCASE_ISO_SLOT`.
## Test plan
- [x] `bats showcase/scripts/__tests__/isolate.bats` → 58/58 green
- [x] `--isolate=9` → `SHOWCASE_ISO_SLOT` exported, slot 9 claimed
- [x] `--isolate=0` → picker dies "slot 0 is reserved"
- [x] `--isolate=99` → picker dies "exceeds ISOLATE_MAX_SLOT=45"
- [x] `shellcheck showcase/scripts/cli/cmd-test.sh` → no new warnings
(only the pre-existing SC2034 on `CMD_TEST_DESC`, consumed by dispatcher
parallel arrays)
- [x] `oxfmt --check showcase/` → clean
## Summary
- remove duplicated OpsPlatformCTA blocks from A2A, CrewAI Flows, and
LangGraph prebuilt components docs
- add missing production CTA cards to integration quickstarts that only
had the inline signup step
- audit shell-docs CTA usage so each integration quickstart has exactly
one OpsPlatformCTA and no duplicate CTA blocks remain
## Verification
- npm run test (showcase/shell-docs)
- npm run typecheck (showcase/shell-docs)
- npm run lint (showcase/shell-docs; existing warnings only)
- npm run build (showcase/shell-docs; existing Next/Turbopack warning
only)
- duplicate CTA scanner: no duplicate CTA blocks found
- quickstart CTA scanner: every integration quickstart has exactly one
OpsPlatformCTA
Items 8 and 9 now show both the SHOWCASE_ISO_SLOT=<N> env-var form and
the --isolate=<N> CLI sugar as equivalent ways to pin the isolation
slot. The env-var form remains valid — the CLI form is a convenience,
not a replacement.
A repo-wide grep confirmed showcase/TESTING.md is the only doc that
references SHOWCASE_ISO_SLOT, so no other docs need updating.
Adds a sugar form of the --isolate flag that pins the isolation slot
directly from the command line:
bin/showcase test agno --d5 --isolate=9
# equivalent to:
SHOWCASE_ISO_SLOT=9 bin/showcase test agno --d5 --isolate
The arg parser splits --isolate=<N> into setting use_isolate=true plus
exporting SHOWCASE_ISO_SLOT=<N>; the existing picker
(_claim_isolate_slot in _common.sh) handles all validation — positive
integer, slot 0 reserved, 1<=N<=ISOLATE_MAX_SLOT, port probe, liveness.
No validation logic is duplicated.
Tests:
- replays the parser branch and verifies SHOWCASE_ISO_SLOT export +
picker pinning
- drives the picker's reserved-slot (N=0) and out-of-range (N=99)
rejections through the arg form to pin the parser->env->picker wiring
- drift guard: sources the REAL cmd-test.sh, stubs apply_isolation, and
snapshots SHOWCASE_ISO_SLOT to catch any future regression of the
parser branch
Help text and TESTING.md updated in a follow-up commit.
## Summary
- add Codex-facing guidance for where CopilotKit docs are authored
- call out shell-docs, framework docs modes, reference nav, snippets,
AG-UI upstream docs, and retired top-level docs
- clarify shell-docs local work should use the shell-docs npm commands
## Verification
- lefthook pre-commit hooks passed during commit
- commit-msg hook passed
## Summary
- Update the CrewAI Flows quickstart init command to use the
CLI-supported framework flag.
## Verification
- Ran shell-docs predev generation as part of local dev server startup.
- Opened http://localhost:3004/crewai-crews/quickstart and verified the
rendered page snapshot contains: `npx copilotkit@latest init --framework
flows`.
- Commit hook passed: check-binaries, test-and-check-packages,
commitlint.
`showToolStatus` only gated the legacy `🔧` rows — the native
`task_update` chunks and the pane "is using `tool`…" composer status
ignored it, so there was no single switch to hide tool-call progress.
Promote `showToolStatus` to the master toggle: when `false`, tool progress
is suppressed on ALL surfaces (native chunks, legacy rows, pane status);
tools still run, only the display is hidden. When `true`, the surface is
still chosen by target (native chunks / legacy rows / pane status, the
latter further gated by the pane's own `toolStatus`).
Flip it off in the slack example (`showToolStatus: false`).
Closes#3190.
## Summary
- update the configurable guide links to the current LangGraph
use-graph-api documentation
- remove an encoded `%23` fragment from the runtime configuration link
- point the AI travel tutorial Studio setup link directly to the current
LangGraph Studio docs
## Verification
- `npx --yes prettier --check
docs/content/docs/integrations/langgraph/configurable.mdx
docs/content/docs/integrations/langgraph/tutorials/ai-travel-app/step-2-langgraph-agent.mdx`
- `git diff --check`
- checked the updated LangChain/LangGraph URLs with `curl -L -I` and
confirmed HTTP 200
Note: `node scripts/check-broken-links.js` was also attempted from
`docs/`, but this sparse checkout does not include all docs pages and
lacks `fumadocs-mdx`, so it reports pre-existing missing internal pages
unrelated to this docs-only change.
The deleted examples/integrations/_intelligence/ dir was referenced by a
"see .../.env.intelligence for the seed value" comment on the
INTELLIGENCE_API_KEY line in 8 integration .env.example files. Removing the
overlay leaves those pointers dangling, so strip them in the same PR.
Localhost INTELLIGENCE_API_URL/GATEWAY_WS_URL defaults are intentionally left
in place — the hosted-only rewrite of those is a launch-coordinated follow-up
(depends on the managed CLI env contract).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Removes examples/integrations/_intelligence/ — the docker-compose +
.env.intelligence + README overlay that the currently-shipped CLI clones
at runtime from CopilotKit@main via fetchIntelligenceOverlay.
DRAFT — do NOT merge until the managed-only CLI build has dropped
fetchIntelligenceOverlay (Intelligence-repo removal) AND been released.
Deleting this dir from main before then breaks the shipped CLI's
threads-framework init (overlay fetch 404s). Merge in lockstep with launch.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The plugin version pins to packages/runtime/package.json, but neither the
lefthook glob nor the plugin-skills-check workflow path filters watched
that file. A routine release bump to the runtime version therefore matched
no trigger and the pin silently rotted between releases (the root cause of
the version drift). Add packages/runtime/package.json to the lefthook glob
and to both the push and pull_request path filters so a version bump
re-runs check:plugin-skills.
The plugin version pins to packages/runtime/package.json, but plugin.json
(1.60.0) and marketplace.json (plugins[0] 1.60.0, metadata 1.57.3) had
rotted behind the runtime package (1.60.2), so check:plugin-skills was
failing on main.
handleVersionSync previously managed only plugin.json.version and
marketplace plugins[0].version, leaving marketplace metadata.version
unmanaged and free to drift independently. Extend it to track
metadata.version against the runtime version too, and re-run the sync to
bring all three fields to 1.60.2.
## Summary
Adds two optional attribution props — `toolCallId` and `agentId` — to
the `useHumanInTheLoop` render callback (`ReactHumanInTheLoop`), so a UI
can tell **which (sub)agent raised an interrupt** and route/resume it
accordingly. This is the front-end piece needed to render and act on
human-in-the-loop stops that originate from a subagent (the
orchestrator/subagent pattern).
Backward compatible and additive — existing HITL render components are
unaffected. No AG-UI protocol change and no runtime change: `toolCallId`
already flowed to the renderer at runtime (this surfaces it in the
type), and `agentId` is sourced from the tool's own registration.
## What changed
- **`types/human-in-the-loop.ts`** — add `toolCallId: string` and
`agentId?: string` to all three render-prop variants, with JSDoc on the
static-vs-runtime distinction.
- **`hooks/use-human-in-the-loop.tsx`** — thread `agentId: tool.agentId`
into the enhanced props; compare `props.status` against the
`ToolCallStatus` enum (was string literals); replace the unreachable `as
any` fallback with a compile-time exhaustiveness check.
- **tests** — assert `toolCallId`/`agentId` reach the render props
through the real `CopilotChat` pipeline (scoped + unscoped), and that
attribution survives the `InProgress → Executing` transition.
- **docs** — document the two new props on the `useHumanInTheLoop`
reference page.
## Decision needed from reviewers — `agentId` semantics
`agentId` is the tool's **static registration scope** (`tool.agentId`),
which is `undefined` for the default unscoped tool — it is **not** the
runtime subagent that raised the interrupt. `toolCallId` is the
load-bearing addition: correlate it with `onToolExecutionStart`'s agent
id for true runtime attribution. The JSDoc states this explicitly.
Options if we want to avoid any ambiguity:
1. **Keep as-is** (documented static scope) — current state.
2. Rename → `registeredAgentId`.
3. Drop `agentId`, ship `toolCallId`-only.
## Follow-ups (separate PR — not in scope here)
These are pre-existing in the HITL `respond`/registration layer
(untouched by this diff) and are the deeper work for full subagent HITL:
- **Route `respond` by `toolCallId`** — a single `resolvePromiseRef`
can't service concurrent interrupts of the *same* tool
(cross-wire/hang). Key resolvers by `toolCallId`.
- **`respond` failure path** — currently a silent no-op when no resolver
is pending, and the handler promise has no rejection on unmount/abort.
- **Re-registration on dynamic `agentId` change** — `useFrontendTool`'s
registration effect deps omit `agentId`/`render`.
## Verification
- `nx run @copilotkit/react-core:test` — 1281 passing (incl. the new
attribution tests).
- `react-core` typecheck clean for the change; `react-core:build` green.
- Reviewed via a 3-round, 7-agent unbiased CR loop; converged with the
bucket-(c) promotion audit clean.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Retitles to 'Build an Agentic Travel App with Oracle Agent Memory, Agent Spec, and CopilotKit' and syncs the recipe with the latest example: adds the memory-ownership diagram + 'what's CopilotKit, what's Oracle' section, documents memory reconciliation/supersession, and updates booking + multi-turn guidance (follow-ups now work via a server-side history-replace). Keeps the CDN media + clone conventions.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The render-callback reference omitted the always-present attribution props.
Document toolCallId (the per-interrupt correlation key) and agentId (static
registration scope, undefined for unscoped tools), matching the type's JSDoc.
Extend the unscoped-tool attribution test to verify toolCallId persists and
agentId stays undefined after the tool moves InProgress -> Executing, not just
at InProgress.
Code-review follow-up. Replace the unreachable `as any` fallback branch with
a compile-time exhaustiveness check (const _: never = props): a newly-added
ToolCallStatus now becomes a type error that must get its own branch, rather
than silently rendering with respond=undefined. Also correct the prop-build
comment (name/description are overwritten with the registration values, not
'normalized'). No behavior change for the three live statuses.
Addresses code-review findings on the HITL attribution change:
- Correct the render-prop JSDoc: agentId is the tool's STATIC registration
scope (undefined for unscoped tools), not the runtime sub-agent; toolCallId
is the key to correlate with runtime attribution (onToolExecutionStart /
event stream). Removes the over-claim that agentId resumes 'the correct
sub-agent'.
- Compare props.status against the ToolCallStatus enum instead of string
literals (removes silent drift risk).
- Inject name/description/agentId in the otherwise-unreachable fallback branch
so attribution is never silently dropped if a status is ever added; cast
the narrowed-never props to a record so the spread typechecks.
Behavior-preserving for the three live statuses; e2e suite green (13/13).
The HITL render callback received args/status/result but no attribution, so
a UI could not tell which run raised an interrupt — the blocker for rendering
and resuming human-in-the-loop stops that originate from a subagent.
- Add toolCallId (already delivered at runtime via the renderer props spread;
this only surfaces it in the type) and agentId (sourced from the tool's own
registration) to all three ReactHumanInTheLoop render-prop variants.
- Thread agentId through useHumanInTheLoop's enhanced props.
- e2e tests assert both reach the render props through the real CopilotChat
pipeline, and that agentId is undefined for an unscoped tool.
No shared renderer-contract or dispatch changes; no runtime behavior change.
Two small follow-ups to #5534 (which made `examples/slack` build from
workspace source) needed to make the Railway deploy actually succeed.
## 1. Pin Node 22 (`.nvmrc`) — the deploy blocker
#5534 merged **without** the Node pin, so Railway still builds on **Node
18**. Now that the build compiles the `@copilotkit/*` libs from source
(tsdown/rolldown), it needs **Node ≥20.12** (`node:util`'s `styleText`)
and fails on 18:
```
SyntaxError: The requested module 'node:util' does not provide an export named 'styleText'
Node.js v18.20.8
```
The builder defaults to 18 from root `engines.node: ">=18"`. A root
**`.nvmrc` = 22** pins the build/dev Node (read by the Railway builder
and nvm/fnm). CI is unaffected (no workflow reads `.nvmrc`), and the
published `engines` runtime contract is left as-is — a build-environment
pin, not a runtime change.
> If your builder ignores `.nvmrc`, set `NIXPACKS_NODE_VERSION=22` on
the service as a fallback.
## 2. Move the `@ai-sdk/mcp` pin to root `pnpm.overrides`
The example pinned `@ai-sdk/mcp` to `1.0.21` (protocolVersion incompat —
`88a2d82`) via its **own** `pnpm.overrides`. That only worked installed
in isolation; as a workspace member pnpm ignores package-level
overrides, so the pin was silently dropped (and pnpm warns).
`packages/runtime` allows `^1.0.21`, so a future lockfile regen could
drift to a newer, incompatible 1.x. Moved it to the **root**
`pnpm.overrides` (runtime is the only consumer) and removed the dead one
from the example.
> Pre-commit `test-and-check-packages` bypassed: the lockfile change
makes nx mark everything affected, and the only failure is the
pre-existing, environmental `@copilotkit/sqlite-runner:test` (native
sqlite on Node 24).
Re-lands the Node pin that was lost when #5534 merged without it. The
Railway slack-example build now compiles the @copilotkit/* libs from source
(tsdown/rolldown), which needs Node >=20.12 (`node:util`'s `styleText`), but
the builder defaults to Node 18 from the root `engines.node: ">=18"` —
failing with "does not provide an export named 'styleText'". Pin the
build/dev Node to 22 (read by the Railway builder and nvm/fnm). CI is
unaffected (no workflow reads .nvmrc) and the published `engines` runtime
contract is left as-is.
The example pinned @ai-sdk/mcp to 1.0.21 (protocolVersion incompat, see
88a2d82) via its own pnpm.overrides. That only took effect when the example
was installed in isolation; as a workspace member pnpm ignores package-level
overrides, so the pin was silently dropped — packages/runtime's `^1.0.21`
could drift to a newer, incompatible 1.x on the next lockfile regen.
Move the override to the root package.json's pnpm.overrides (runtime is the
only consumer, so this enforces exactly 1.0.21 with no wider impact) and
remove the now-dead override from the example (also silences the pnpm warning
that surfaced once the example became a workspace member).
Per review, keep this PR docs-only. Restores defineToolCallRenderer and
useRenderTool (and its test) to main. The specific-tool opt-out example
now passes a pass-through schema (parameters: z.any()) since the named
overload requires a schema.
## Problem
`examples/slack` is deployed on Railway and declared its sibling
packages as **npm version ranges** (`@copilotkit/bot: ~0.0.2`, …).
Because the service resolves those from the registry, every PR that
changes the packages required a brittle dance:
1. Merge → Railway redeploys → installs the **old** published packages →
broken/stale.
2. Manually release the npm packages.
3. Bump the example's versions → that change finally triggers a redeploy
that pulls the new release.
A chicken-and-egg with a broken-deploy window in between.
## Fix
Consume the siblings via the **`workspace:*`** protocol (the example is
`private`, so this never affects publishing) so the example always
builds from **in-repo source**, and add a graph-aware `build` script
that compiles the workspace libs it imports (and their deps) via Nx.
- `examples/slack/package.json`: `@copilotkit/bot`, `-slack`,
`-discord`, `-ui`, `runtime` → `workspace:*`; new `build` script (`nx
run-many -t build -p @copilotkit/bot-slack @copilotkit/bot-discord
@copilotkit/runtime`).
- `pnpm-lock.yaml`: regenerated (drops the registry trees those deps
pulled).
- README: documents the Railway settings and the copy-out caveat.
As a side benefit, this also removes the local "rebuild → re-sync
injected copy" friction — `workspace:*` symlinks the packages, so a
rebuilt `dist` is seen live.
## Required Railway config (apply in the dashboard)
The service must build **as a workspace member from the repo root** —
`packages/**` lives above `examples/slack`, so a service rooted at
`/examples/slack` cannot watch or build it.
| Setting | Value |
|---|---|
| **Root Directory** | `/` (repo root) — **change from
`/examples/slack`** |
| **Build Command** | `pnpm install && pnpm --filter slack-example
build` |
| **Start Command** | `pnpm --filter slack-example start` (bot) / `pnpm
--filter slack-example run runtime` (runtime) |
| **Watch Paths** | `packages/**`, `examples/slack/**`,
`pnpm-lock.yaml`, `package.json` |
## Result
- A `packages/**` change redeploys the example with the new code
**immediately** — no release required.
- `npm publish` becomes an **independent, manual** step. No more
publish-then-bump dance.
## Verification
- `pnpm --filter slack-example build` ✓ (builds 3 libs + 5 deps via Nx)
- `pnpm --filter slack-example check-types` ✓
- `pnpm --filter slack-example test` ✓ (38 tests)
> Pre-commit `test-and-check-packages` was bypassed for the commit: the
lockfile change makes nx mark everything affected, and the only failure
is a pre-existing, environmental `@copilotkit/sqlite-runner:test` break
(native sqlite on Node 24) unrelated to this change.
`examples/slack/pnpm-lock.yaml` only existed for the old isolated deploy
(root dir `/examples/slack`, `pnpm install --ignore-workspace
--frozen-lockfile` resolving the @copilotkit/* deps from npm). Now that the
example is a workspace member built from source (`workspace:*`, root-dir
`/`), pnpm uses the single root `pnpm-lock.yaml`; the per-example lock is
never consulted and was left stale — it still pins the published `~0.0.2`
versions, which contradicts the `workspace:*` package.json and would break
any `--frozen-lockfile` install.
Add a bot-whatsapp release scope to release.config.json and the matching
workflow_dispatch scope dropdowns in publish-release / stable-release / canary,
so the package can be released via the manual CI trigger like bot-slack.
The example declared its sibling @copilotkit/* packages as npm version
ranges, so the Railway service (which builds examples/slack in isolation)
resolved them from the registry — forcing a "publish first, then bump the
example" dance on every PR, with a broken deploy window in between.
Switch those deps to the workspace:* protocol (the example is private, so
it never affects publishing) so the example always builds from in-repo
source, and add a graph-aware `build` script that compiles the workspace
libs it imports (and their deps) via Nx. README documents the Railway
settings (root dir / build / start / watch paths) and the copy-out caveat.
Result: a packages/** change redeploys the example with the new code
immediately, and npm publishing becomes an independent manual step.
Point all @copilotkit/* deps at workspace:* so the example uses local source (the Telegram work is unpublished and depends on the core HITL fix). Add global unhandledRejection/uncaughtException handlers and guard the onMention/onThreadStarted handlers so a failed turn cannot crash the bot. Update deploy docs.
Fire agent turns async so a blocking HITL awaitChoice cannot pause grammy sequential polling (which deadlocked the poll loop and drained the process). Add a bot.catch error boundary so update-processing errors are logged and polling continues. Fold a replied-to message (media + quoted text) into the turn. Decode text-like uploads (CSV/JSON/XML/text) to a text part instead of an unsupported binary file part.
awaitChoice resolved the waiter with evt.value, which platforms whose callback payload cannot carry it (Telegram, 64-byte callback_data) deliver as undefined. The registry now returns the clicked element value from dispatch, and create-bot falls back to it when the event has none. Slack (value-in-payload) is unchanged.
Bring the Slack adapter up to the current native streaming API surface
(chat.startStream/appendStream/stopStream, GA Oct 2025) and remove the
type-erasure workarounds.
- Remove `as unknown as Parameters<...>` casts in favor of the SDK's typed
args (ChatStartStream/AppendStream/StopStream/PostMessage/UpdateArguments).
- Stream a whole turn into ONE message: drop the per-message continuation
splitting (no documented cumulative cap; matches vercel/chat), keeping the
12k per-append chunking.
- Surface tool progress as native in-message `task_update` chunks
(task_display_mode "timeline"), degrading to `🔧` rows where
structured chunks are unavailable.
- Add opt-in AI feedback buttons via `slack({ feedback })` — a typed
context_actions/feedback_buttons row attached at stopStream, with clicks
routed adapter-locally (bypassing the engine's interaction dispatch).
- Scope recipient_user_id/recipient_team_id to channel targets only.
- Lower the native flush floor to ~600ms (appendStream Tier-4), legacy stays
800ms.
Engine: add an optional, backward-compatible RunRenderer.finish() hook called
after runAgentLoop so a turn-scoped renderer can finalize its stream.
Unify WhatsApp with main's Slack+Discord multi-adapter demo: WhatsApp becomes a
third env-gated platform block in examples/slack/app/index.ts (listening on
Railway $PORT, with a malformed-PORT guard). Keep the platform-aware
senderContext (also fixes the Discord 'Slack user' label); drop the superseded
buildAdapters helper for main's inline per-platform pattern. package.json takes
main's ~0.0.2 bumps + bot-discord and adds bot-whatsapp (workspace:~); README
intro + deploy section cover all three surfaces.
Atai Barkai