[Bug] Task tool in nested subSession dispatches to wrong agent (different agent responds instead of requested subagent_type) #16303
Description
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
- Start a primary agent session (e.g.
sisyphus) - Have the primary agent call
task(subagent_type="some-agent", ...)→ this creates subSession A - Inside subSession A, call
task(subagent_type="oracle", description="...")→ this creates subSession B - Observe that subSession B receives a
user|oraclemessage but all assistant responses come from a different agent (e.g.Hephaestus) - The TUI shows
0 toolcalls · 0msfor 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 showsagent=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.