You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Feature]: Agents panel should also show CLI-delegated child agents (codex exec / opencode run / etc.), not only provider-native subagents #5479
I included enough detail to reproduce or investigate.
Area
apps/web
Feature request
Render CLI-delegated child agents in the Agents panel, not only provider-native subagents.
PR #5219 ("native subagent & workflow observability", v0.0.32-nightly.20260806.1012) is a great step: Claude Code Task-tool spawns and Codex collab agents now show up in the Agents panel with model, tokens, tool count, and status. Thank you for this.
But a very common delegation shape is still invisible there: the primary agent spawning another vendor's agent CLI as a child process — e.g. a Claude thread running codex exec "…" or opencode run "…" --auto --format json through its Bash tool (foreground or backgrounded). Multi-vendor routing like this is how many of us pick a cheap/fast model per task while keeping one conversation.
Repro (today, on v0.0.32-nightly.20260806.1012):
In a Claude thread, spawn a native subagent via the Task tool → it appears in the Agents panel with full attribution. ✅
In the same thread, ask the agent to run opencode run "say hi" --auto --format json or codex exec "say hi" as a background Bash command → the child agent runs to completion but never appears in the Agents panel; the only trace is the generic running-task line in the transcript. ❌
Both are "my thread is running a fleet," but only one is observable in the panel.
Suggested directions (either would help):
Heuristic attribution: recognize well-known agent CLIs (codex exec, opencode run, claude -p, grok, cursor-agent, …) in Bash/exec tool events and render them as panel members with elapsed time and status derived from the process/tool lifecycle.
Explicit annotation: a documented way for the primary agent (or a wrapper script) to declare "this command is a child agent: vendor, model, task label" so the panel can render it first-class — this seems to fit the Orchestrator v2 schema alignment mentioned in feat: native subagent & workflow observability #5219.
Related: #5043 (same gap reported on the thread/transcript surface before the Agents panel existed).
Thanks for opening this. I have a related observability request for the Agents panel.
For every visible subagent, could the panel also show runtime attribution metadata when available?
Provider/runtime: Codex, Claude, OpenCode, etc.
Model ID
Reasoning effort/level, such as low, medium, high, or extra-high
Status, elapsed time, and token usage
In my current view, an agent can appear as running without making it clear which model or reasoning configuration is actually being used. That makes it difficult to understand cost, latency, capability differences, and whether the requested configuration was applied.
I am not asking for private chain-of-thought or raw internal reasoning. I only mean the configured/runtime metadata. A compact secondary line or expandable details view would be enough. If a provider does not expose a field, displaying "Unknown" or "Not reported" would be helpful.
This would make the Agents panel much more useful for monitoring and debugging multi-agent workflows.
Before submitting
Area
apps/web
Feature request
Render CLI-delegated child agents in the Agents panel, not only provider-native subagents.
PR #5219 ("native subagent & workflow observability",
v0.0.32-nightly.20260806.1012) is a great step: Claude Code Task-tool spawns and Codex collab agents now show up in the Agents panel with model, tokens, tool count, and status. Thank you for this.But a very common delegation shape is still invisible there: the primary agent spawning another vendor's agent CLI as a child process — e.g. a Claude thread running
codex exec "…"oropencode run "…" --auto --format jsonthrough its Bash tool (foreground or backgrounded). Multi-vendor routing like this is how many of us pick a cheap/fast model per task while keeping one conversation.Repro (today, on
v0.0.32-nightly.20260806.1012):opencode run "say hi" --auto --format jsonorcodex exec "say hi"as a background Bash command → the child agent runs to completion but never appears in the Agents panel; the only trace is the generic running-task line in the transcript. ❌Both are "my thread is running a fleet," but only one is observable in the panel.
Suggested directions (either would help):
codex exec,opencode run,claude -p,grok,cursor-agent, …) in Bash/exec tool events and render them as panel members with elapsed time and status derived from the process/tool lifecycle.Related: #5043 (same gap reported on the thread/transcript surface before the Agents panel existed).