Repository navigation
[bug] Explore Task sub-agent is non-interactable 0 toolcalls. #14424
Description
Description
Claude Sonnet 4.6 likes to use explore sub-agents a lot. Sub-agents in Opencode are great, in that you can see their progress by clicking on them. Unfortunately when Opencode has an explore launched it is non-interactive, you can't click into it to see progress, and the toolcalls remains at 0 until it finishes and shoots up to whatever number it eventually ends at. Only after it completes can you dive into the explore to see what was done.
Can you make the Explore sub-agent update real-time as toolcalls are made, and if possible let you drill in like a normal sub-agent?
Plugins
"plugin": [],
OpenCode version
1.2.6
Steps to reproduce
Ask Claude Sonnet 4.6 to plan any mid-sized task. Of all the agents this one seems to really like to do an Explore.
Screenshot and/or share link
Operating System
macOS Version 26.1 (25B78)
Terminal
iTerm2
Reacted by apleynes, chengxuanli00 and Issam Bousfiha
Metadata
Metadata
Assignees
Labels
No labels
Activity
Greg-Myers-SB commentedon Feb 20, 2026
I actually wonder if this may be a Sonnet 4.6 specific bug as 4.5 can do explore as sub-agent successfully?
Edit: I spoke too soon, managed to get Sonnet 4.5 to get stuck in the same place.
[-]Explore sub-agent is non-interactable[/-][+][bug] Explore Task sub-agent is non-interactable 0 toolcalls.[/+]Greg-Myers-SB commentedon Feb 20, 2026
I figured out you can ctrl+x right to get into the explore task even though it doesn't let you click, doesn't show the ctrl+x right text, and doesn't update the UI. Looks like this is primarily a UI bug.
hydroplexus commentedon Feb 20, 2026
Sometimes I faced the same problem. But I use glm-7. The agent just freezes and does nothing.
apleynes commentedon Feb 21, 2026
Happens with devstral 2 (mistral/devstral-2512) as well on my end. I can confirm the "ctrl+x right" trick works and I've noticed that the agent is doing work so it is primarily a UI bug. The subagent eventually finishes and the tool call and subagent session is then visible.
Happens with any sub-agent launched through the task tool (also with custom sub agents)
Opencode 1.2.6.
loxoron218 commentedon Feb 23, 2026
I'm using GLM5 and GLM4.7 and I'm also experiencing this issue.
Opencode 1.2.10
OS-Lihua commentedon Mar 1, 2026
I've also encountered this issue. I was using Claude Opus 4.6.
guazi04 commentedon Mar 8, 2026
Root Cause Analysis
Traced through the code — the issue is a timing gap between tool part rendering and session creation:
packages/opencode/src/tool/task.tsL66-117:Session.create()at L72 — happens insidetool.execute()ctx.metadata({ sessionId })at L111 — also insideexecute()When an LLM outputs N
tool_useblocks simultaneously, the UI receives all N tool parts immediately (status: pending/running). Butexecute()runs with limited concurrency — queued tasks haven't calledSession.create()yet, so theirmetadata.sessionIdis empty.UI impact:
cli/cmd/tui/routes/session/index.tsxL1965-2031):tools()andduration()are derived from child session messages. No session = no messages = "0 toolcalls · 0ms". TheonClickhandler is guarded byif (props.metadata.sessionId).ui/src/components/message-part.tsxL1482-1561):href()depends onmetadata.sessionId. Without it, description renders as plain text (<ToolText>) instead of a clickable<TaskLink>.Suggested fix (UI layer):
pending/runningandsessionIdis not yet available, show a loading shimmer instead of "0 toolcalls · 0ms"metadata.sessionIdarrives via SSE, the component should reactively update to become clickable (SolidJS reactivity should handle this, but the initial render state is misleading)github-actions commentedon Jul 4, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.