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
Although the subagents do not have the task tool but they sometimes delegate to other agents. I have noticed this happening after v1.0.68, but I can't tell which version it was.
Unfortunately the sub-agent got stuck somewhere, and I can't navigate to the sub-sub-agents either to see what is happening.
OpenCode version
v1.0.72
Steps to reproduce
Unfortunately I can't reliably produce a step for this. This is quite random. In the same session.
the issue here is in the new agent loop it tries to resolve the tools from the last user message
but it's possible to insert a user message without any tools, need to think about how to resolve this/if this is even a good pattern i introduced
I asked Claude to help investigate this and here's what it found. I'm not sure if this holds any truth to it, but I'm hoping this helps pinpointing the problem.
What Claude Found
The issue seems to trace back to the agent loop refactor in commit a1214ff. @thdxr you're right about it being tool resolution from user messages, but there's a specific execution path that causes it.
The Problem
File:packages/opencode/src/session/prompt.ts
The refactor extracted loop() as a separately callable function (line 229). The server can now call it directly from packages/opencode/src/server/server.ts:801:
awaitSessionPrompt.loop(id)
This bypasses the tool restrictions that were set up in the original prompt() call.
How It Happens
Primary agent delegates via TaskTool with restricted tools: {task: false, todoread: false, todowrite: false}
SessionPrompt.prompt() creates the user message with these restrictions
loop(sessionID) gets called-works fine initially
Later, the server calls SessionPrompt.loop(sessionID) directly for session continuation
loop() tries to resolve tools from lastUser.tools (line 465), but if that message doesn't have complete tool restrictions, it falls back to agent defaults
Subagent ends up with task tool access
Before vs After
Before refactor: The loop was internal to prompt(), so the tool context was consistent.
After refactor: Loop is exported and can be called independently, which breaks the guarantee that tool restrictions stick around.
Code Locations
Tool resolution in the loop (prompt.ts:461-467):
consttools=awaitresolveTools({
agent,
sessionID,model: lastUser.model,tools: lastUser.tools,// Can be undefined/incomplete
processor,})
This would explain why it's random-it depends on the message history state when the server decides to continue the session.
Interesting Finding
With current implementation one issue we have is that when the sub-agent delegates, there is no way of navigating to the sub-sub-agent view/session to see what it is doing. However with the following change it is actually possible to navigate. It doesn't fix the issue in this conversation, but I thought it would be interesting to know:
@rekram1-node I did a bit of digging and I found some interesting lines in the code, some defaults might be the issue. I've applied this patch locally and I haven't seen the issue yet.
TLDR; there is something weird going on, but the default subagent can't be the build agent, it should have been the general agent.
Activity
arsham commentedon Nov 18, 2025
Interesting find: https://opencode.ai/s/j0eMtkw1
This shows me some instructions that are only accessible by the primary agents
I can confirm my subagent is set to
"mode": "subagent". Here is a part of my config:rekram1-node commentedon Nov 18, 2025
ill check it out
thdxr commentedon Nov 19, 2025
the issue here is in the new agent loop it tries to resolve the tools from the last user message
but it's possible to insert a user message without any tools, need to think about how to resolve this/if this is even a good pattern i introduced
arsham commentedon Nov 20, 2025
I asked Claude to help investigate this and here's what it found. I'm not sure if this holds any truth to it, but I'm hoping this helps pinpointing the problem.
What Claude Found
The issue seems to trace back to the agent loop refactor in commit a1214ff. @thdxr you're right about it being tool resolution from user messages, but there's a specific execution path that causes it.
The Problem
File:
packages/opencode/src/session/prompt.tsThe refactor extracted
loop()as a separately callable function (line 229). The server can now call it directly frompackages/opencode/src/server/server.ts:801:This bypasses the tool restrictions that were set up in the original
prompt()call.How It Happens
{task: false, todoread: false, todowrite: false}SessionPrompt.prompt()creates the user message with these restrictionsloop(sessionID)gets called-works fine initiallySessionPrompt.loop(sessionID)directly for session continuationloop()tries to resolve tools fromlastUser.tools(line 465), but if that message doesn't have complete tool restrictions, it falls back to agent defaultsBefore vs After
Before refactor: The loop was internal to
prompt(), so the tool context was consistent.After refactor: Loop is exported and can be called independently, which breaks the guarantee that tool restrictions stick around.
Code Locations
Tool resolution in the loop (
prompt.ts:461-467):This would explain why it's random-it depends on the message history state when the server decides to continue the session.
Interesting Finding
With current implementation one issue we have is that when the sub-agent delegates, there is no way of navigating to the sub-sub-agent view/session to see what it is doing. However with the following change it is actually possible to navigate. It doesn't fix the issue in this conversation, but I thought it would be interesting to know:
arsham commentedon Nov 28, 2025
@rekram1-node I did a bit of digging and I found some interesting lines in the code, some defaults might be the issue. I've applied this patch locally and I haven't seen the issue yet.
TLDR; there is something weird going on, but the default subagent can't be the
buildagent, it should have been thegeneralagent.I am not happy about this though, this looks like a band-aid to me. A proper fix would be figuring out why sometimes the agent is not set properly.
rekram1-node commentedon Nov 29, 2025
ill take a looksie