Tasks/Subagents with Codex / OpenAI are frequently getting stuck with no timeout/retry, which then hangs the session forever

Description

I use OpenAI as provider with Codex 5.2 Xhigh as the model. My AGENTS.md has explicit instructions to make agents use Tasks/Subagents as often as possible. My subagents are frequently getting stuck (this time after a message talks about 'invalid session ID'), and then the session hangs forever because there is no automatic timeout/retry.

Plugins

None

OpenCode version

1.1.48

Steps to reproduce

Just use Codex + OpenAI a lot with explicit instructions in AGENTS.md to use Tasks/Subagents liberally
Eventually, a subagent gets stuck and the session hangs forever because apparently there is not timeout/retry

Screenshot and/or share link

Operating System

Fedora 43 Silverblue

Terminal

GNOME Terminal (Ptyxis)

This issue might be a duplicate of existing issues. Please check:

Task Tool Timeouts & Early Termination in Multi-Agent Conductor Pattern #6792: Task Tool Timeouts & Early Termination in Multi-Agent Conductor Pattern - describes subagents failing after ~60s with only session_id returned, similar stuck behavior with timeouts
TUI: Parent session appears stuck "loading" when subagent is blocked (waiting user input / hanging tool call); lack of visibility and recovery UX #10802: TUI: Parent session appears stuck "loading" when subagent is blocked - describes parent sessions appearing to hang when subagents are blocked or waiting
main agent hangs because of subagent (explore) #9003: Main agent hangs because of subagent (explore) - describes sessions hanging when subagent completes work but doesn't return to parent
[FEATURE]: Configurable command timeout in config.json #3950: Configurable command timeout in config.json - requests ability to configure timeout duration for long-running operations
Opencode Hangs when used as CLI tool #5888: Opencode Hangs when used as CLI tool - describes hanging behavior with unclear debug information

Feel free to ignore if none of these address your specific case.

Doesn't seem to be a duplicate.

same here with another models (minimax and glm) API stops do respond and the session is stuck forever

@dcominottim

Is this still persisting in 1.1.51 @dcominottim & @victorhramos-dev

Is this still persisting in 1.1.51 @dcominottim & @victorhramos-dev

Yes, its just stuck without any response from provider api like in the middle of thinking sometimes

Are you sure it's actually stuck? I think it's just because if u click the subagent session there isn't any loading indicator.

I've never managed to replicate an actual stuck case but if you are using high/xhigh know that the reasoning the model does can take a long time AND we can only show the thinking summaries so there is even more latency because of that

Are you sure it's actually stuck? I think it's just because if u click the subagent session there isn't any loading indicator.

I've never managed to replicate an actual stuck case but if you are using high/xhigh know that the reasoning the model does can take a long time AND we can only show the thinking summaries so there is even more latency because of that

Not totally sure because I haven't used opencode + Codex much in the last week, but I awaited >20 minutes and nothing else got updated in the main screen or subagent sections before I submitted the bug report. A visual indicator could be an interesting feedback mechanism.

I can confirm this issue but I'm unsure how to get any debug information? The system prompt is sent to the subagent and then it just hangs for gpt-5.3-codex. I've tried all of the openai connection options with no success. This is a recent issue (in the past week) and it was working well before hand. I've had to move to using Opus for the time being but would love to not be using the Claude usage budget for codex's workload.

Experiencing this same stuck behavior on macOS with Anthropic/Claude models (not just OpenAI/Codex). After investigating the oh-my-opencode plugin source (v3.11.2), I found the root cause is in the notification delivery pipeline of the BackgroundManager:

tryCompleteTask() changes task status to "completed" immediately, but notifyParentSession() is async and can fail silently
Once status is "completed", hasRunningTasks() returns false → stop button disappears and polling stops
But the parent session never received the completion notification → stuck "waiting for background agents" forever
Notification errors are swallowed by catch(() => {}) with no retry mechanism
Only AbortedSessionError gets fallback handling — all other errors (timeouts, transient failures) are lost

Filed detailed analysis with code references as oh-my-openagent #2627.

This may also explain the behavior some of you are seeing — the subagent/task may have actually completed but the notification back to the parent session failed silently, making it appear stuck.

I'm having the same issue. In most cases it looks like the subagent received instructions and doesn't do anything with them

I'm having the same issue. The only way to get aruond is manully interrupt it and ask it to carry on.

I am having the same issue. Some subagents seem done, but the parent agent is waiting for the result and not doing anything. Some subagents fail when running tools and never continue. Some subagents just get stuck on tool calls and never finish. I am on Mac with Opencode v1.4.3

This is happening for me as well and more frequently recently. As you can see in the image below:

This is the agent that is stuck:

I've been waiting for that agent for 20 mins or so. Have to interrupt the main agent and do it again and hope things don't get stuck. In most cases I have to change the model.

As you can see it made a few invalid calls and then ... dead.

Yeah, it is really not possible or rather quite hard to use opencode run in scripts as it randomly gets stuck; in my case I normally observe that explore agent finishes but its parent build agent thinks that it is still running, and that makes them stuck forever until killed by a timeout wrapper I had to write.

Problem is, it is hard to come up with one-size-fits-all timeout value, so the workaround is very far from ideal.

If it helps, my usage scenario is binding opencode with llama.cpp, so for one thing it is not really well suited for parallel execution; not sure if this could be related or not.

Adding production-scale evidence to strengthen the case for sub-agent timeouts.

Production Data (6-month window, ~2000 sessions, 775 sub-sessions)

207 sessions with MessageAbortedError — many caused by sub-agent timeouts
Top-level sessions aborted:
- 29 fusion-deep-research sessions (avg 104h duration, ~103M total tokens each)
- 7 task-executor sessions (avg 99h duration)
- 5 repo-reviewer sessions (avg 169h duration)
4 orphan sub-sessions currently stuck in tool-calls state with terminated parents:
- ses_09e82cb4 (explore) — parent completed days ago
- ses_0c77d7ac (explore) — parent completed
- ses_0ddbf20a (critical-thinking) — parent completed
- ses_117c5c57 (critical-thinking) — parent completed
5 mass-abort events where 3+ sub-agents were terminated together:
- ses_10049ce8: 4 children aborted together
- ses_0c781f98: 3 children aborted together
- ses_0d4228cd: 3 children aborted together
- ses_0dab015c2: 3 children aborted together
- ses_11846e3e: 3 children aborted together

Case Study: ses_0dab015c2

FDR launched 5 sub-agents in parallel — 2 completed successfully, 3 got stuck. FDR waited 5.7 hours before the entire session was aborted, losing even the 2 successful results (176K tokens wasted).

Root cause pattern

This is the same hang-forever / no-timeout issue reported here, confirmed at production scale across multiple agent types (fusion-deep-research, task-executor, repo-reviewer). The proposed fix — a configurable timeout parameter on sub-agent invocation — would directly prevent these multi-hour hangs and the cascading loss of completed sibling work when one sub-agent gets stuck.

(Consolidated from my duplicate issue; closing that one per the bot's duplicate-detection suggestion.)

Adding another data point with a provider/model combination not yet represented here.

Setup: opencode 1.17.16, served via opencode serve, using a custom OpenAI-compatible provider pointed at Bifrost (an LLM gateway), which in turn routes to OpenRouter for the affected models.

Models affected: deepseek-v4-pro and kimi-k3 (both via OpenRouter). GLM-5.2 (self-hosted via vLLM, same setup otherwise) does not exhibit this.

Reproduction (isolated from any of our own infra): a ~60-line script talks directly to opencode serve's HTTP/SSE API — creates a session, sends a prompt that triggers task(subagent_type="explore"), subscribes to /event, and replies to permission.asked events exactly as a normal client would. Sequence observed:

task tool permission requested → replied always → 200 OK.
Tool status → running.
Zero further events, ever. No permission.asked from inside the subagent, no tool output, no error, no session-idle. Confirmed the opencode serve process itself stays alive and otherwise responsive — this specific call is just permanently wedged.

Direct (non-task) tool use with the same models — bash, read, write, edit, including multiple real permission round-trips — works completely fine. It's isolated to the task/subagent path specifically.

Happy to share the repro script if useful. This matches the pattern already described in this issue (no timeout on the sub-agent's own LLM call), just with a different provider/model combination than what's here so far.

Happens to me all the time when calling /review. Did anybody find a workaround?

session: recover from dropped model streams with no terminal event

@yajo

@yajo after tracking this and similar issues (e.g. #13841) for a few months, my ultimate workaround (yes I tried a few within opencode framework before I switched) was to give pi a try. There are also tau, Hermes Agent, etc. Opencode team clearly ignores any PRs or issues they are not interested in, so .. basically this is not how it works. It's a nice harness, just .. I might be wrong, but it seems as PRs and issues -- well, they do not look like they are a part of its workflow. So kinda take it or leave it.

PS. pi is also significantly faster due to low prompt overhead.

@gf-mse

Hello @gf-mse

I would be interested to hear your opinion of Pi with subagents after a few weeks of using it. Please post here if it is not too much trouble.

Subagents and the permission system are the main reasons I use Opencode rather than Pi. Like you, I made a genuine attempt about a month ago to use Pi in my workflow, but it was nowhere near as practical as Opencode.
There was no usable and bug-free subagent package for Pi at the time. I could not get on with the offered UI options, and the subagent bugs on the Pi side were much worse than this one in Opencode. The issue in Opencode is that a subagent gets stuck and does nothing, while on Pi a subagent would continue running and modifying files even though its parent agent "thinks" the child has finished and starts another subagent to modify same files in the same project. So instead of losing time with Opencode, on Pi I would have ended up with data loss if not for version control.

@neowit

@neowit while I can once in a while leave a moderately disappointed note in the comments, I would do my best to refrain of anything off-topic (even if I wouldn't believe that most issues here would ever get anything but be closed "to keep things neat" after a certain period of inactivity).

TL;DR: forked the discussion here : gf-mse/tau-dev#1 ; I must say, I did not use "discussion" feature much yet, so please ping me if it somehow does not work for you.

I had to move to Goose because of RAM consumption (opencode ate too much). Happens to support subagents that actually work. Doesn't include a /review skill, but writing it is a piece of cake. Just in case it helps someone!

The timeout and retry problem here is fixed in #46890 (v1.18.27) and #49229 (v2.0.22).

Everything is much better on v2: https://opencode.ai/v2/docs

Navigation Menu

Repository navigation

Tasks/Subagents with Codex / OpenAI are frequently getting stuck with no timeout/retry, which then hangs the session forever #11865

Description

Plugins

OpenCode version

Steps to reproduce

Screenshot and/or share link

Operating System

Terminal

5 remaining items

Production Data (6-month window, ~2000 sessions, 775 sub-sessions)

Case Study: ses_0dab015c2

Root cause pattern

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Tasks/Subagents with Codex / OpenAI are frequently getting stuck with no timeout/retry, which then hangs the session forever #11865

Description

Description

Plugins

OpenCode version

Steps to reproduce

Screenshot and/or share link

Operating System

Terminal

Activity

github-actions commented on Feb 3, 2026

dcominottim commented on Feb 3, 2026

victorhramos-dev commented on Feb 4, 2026

R44VC0RP commented on Feb 4, 2026

victorhramos-dev commented on Feb 4, 2026

rekram1-node commented on Feb 5, 2026

dcominottim commented on Feb 9, 2026

the0rem commented on Feb 14, 2026

neocody commented on Mar 16, 2026

andybarilla commented on Mar 18, 2026

stevenxi commented on Mar 24, 2026

michalsalat commented on Apr 14, 2026

aboo commented on Apr 30, 2026

5 remaining items

gf-mse commented on Jun 17, 2026

zxkjack123 commented on Jul 16, 2026

Production Data (6-month window, ~2000 sessions, 775 sub-sessions)

Case Study: ses_0dab015c2

Root cause pattern

marko-k0 commented on Aug 7, 2026

yajo commented on Aug 20, 2026

gf-mse commented on Sep 23, 2026

neowit commented on Sep 23, 2026

gf-mse commented on Sep 23, 2026

yajo commented on Sep 25, 2026

rekram1-node commented on Oct 2, 2026

rekram1-node commented on Oct 2, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions