[Bug] Task tool in nested subSession dispatches to wrong agent (different agent responds instead of requested subagent_type)

[chuck-ma]

Description

When a subagent session (spawned via the task tool) itself calls the task tool to spawn a specific subagent, the resulting session receives messages from a different agent than the one requested in subagent_type. The requested agent's user message is written to the session, but the assistant responses come from a completely different agent.

In other words: calling task(subagent_type="oracle") from inside a subSession results in a session where Hephaestus (Deep Agent) responds instead of Oracle.

Nesting structure

main session (no parent)
  └── subSession A  (parentID = main session)  ← task() called here
        └── subSession B  (parentID = subSession A)  ← oracle task requested, wrong agent responds

Steps to reproduce

1. Start a primary agent session (e.g. sisyphus)
2. Have the primary agent call task(subagent_type="some-agent", ...) → this creates subSession A
3. Inside subSession A, call task(subagent_type="oracle", description="...") → this creates subSession B
4. Observe that subSession B receives a user|oracle message but all assistant responses come from a different agent (e.g. Hephaestus)
5. The TUI shows 0 toolcalls · 0ms for the Oracle task entry, while a different agent session is actually processing it

Database evidence

Query against ~/.local/share/opencode/opencode.db:

SELECT session_id, json_extract(data,'$.role'), json_extract(data,'$.agent'),
       json_extract(data,'$.modelID'), json_extract(data,'$.providerID'),
       datetime(time_created/1000, 'unixepoch', 'localtime')
FROM message
WHERE session_id = 'ses_33e36a2c4ffeOBmLGk775dED8W'
ORDER BY time_created ASC;

Result:

user   | oracle                  | (null)  | (null)         | 14:15:25  ← task was intended for oracle
user   | Hephaestus (Deep Agent) | (null)  | (null)         | 14:15:25  ← unexpected: different agent
assistant | Hephaestus (Deep Agent) | gpt-5.4 | cliproxy_gpt | 14:15:25  ← Hephaestus responds, not Oracle
assistant | Hephaestus (Deep Agent) | gpt-5.4 | cliproxy_gpt | 14:15:33
... (all subsequent messages are Hephaestus)

Session record:

id:        ses_33e36a2c4ffeOBmLGk775dED8W
parent_id: ses_33ea947d0ffe0CIh5t1O4pwNJ0   ← this parent is itself a subagent session
title:     Investigate why @oracle no longer works (@oracle subagent)
created:   2026-03-06 14:15:25

Key observation

• Calling task(subagent_type="oracle") directly from the primary session works correctly and consistently (DB shows agent=oracle, modelID=gpt-5.4, providerID=cliproxy_gpt)
• The same call from inside a subSession (1 level of nesting) routes to the wrong agent
• The session title correctly says (@oracle subagent) — the session was created for oracle — but the wrong agent ends up handling it

Suspected area

task.ts creates the subSession correctly (parentID = ctx.sessionID), but something in SessionPrompt.prompt() or the agent resolution path may be using the wrong context when called from within a non-primary session, causing it to pick up the parent session's agent instead of the requested subagent_type.

Confirmed working

• Direct call from primary session: task(subagent_type="oracle") → Oracle responds with correct model ✅
• Oracle called standalone (not via task nesting): works fine ✅

Environment

• OpenCode version: 1.2.20
• OS: macOS 25.2.0 (Darwin arm64)
• Terminal: WarpTerminal
• No relevant plugins affecting agent routing

Additional context

Note: the title of the failed session itself was "Investigate why @oracle no longer works" — this was a debugging task, and the oracle call inside it also failed in the same way, suggesting the bug is consistently reproducible for any nested subSession depth ≥ 2.

[vicary]

I am creating a dynamic agent swarm (router -> router -> router -> worker), and when leaf agents try to write files, it just hung until timeout.

The model is in turn keep retrying without any response.

~ Preparing write... 
~ Preparing write... 
~ Preparing write... 
~ Preparing write... 
~ Preparing write... 
~ Preparing write... 
~ Preparing write... 
~ Preparing write... 
~ Preparing write... 
~ Preparing write... 
~ Preparing write...

The same model of Sonnet 4.6 can sometimes write (<10% success rate), and it can always write with 1 level of delegation (main -> subagent).

I am suspecting the same issue, is there a way I can further proof that we are having the same issue?

EDIT 20260313

This only happens with Claude models, GPT works fine.

EDIT 20260317

opencode is persisting a pending tool call in their sqlite, when the stream is interrupted, reconnection replays will always stuck there. Claude models tend to do drop connections at large file edits.

opencode just need to stop committing tool calls before the stream actually starts, but given how much they care about PRs, I am saving my time.

[chuck-ma]

@adamdotdevin