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

[dcominottim]

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

1. Just use Codex + OpenAI a lot with explicit instructions in AGENTS.md to use Tasks/Subagents liberally
2. 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)

[github-actions]

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.

[dcominottim]

Doesn't seem to be a duplicate.

[victorhramos-dev]

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

[R44VC0RP]

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

[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

[rekram1-node]

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

[dcominottim]

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.

[the0rem]

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.

[neocody]

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:

1. tryCompleteTask() changes task status to "completed" immediately, but notifyParentSession() is async and can fail silently
2. Once status is "completed", hasRunningTasks() returns false → stop button disappears and polling stops
3. But the parent session never received the completion notification → stuck "waiting for background agents" forever
4. Notification errors are swallowed by catch(() => {}) with no retry mechanism
5. 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.

[andybarilla]

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

[stevenxi]

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

[michalsalat]

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

[aboo]

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.