Repository navigation
Desktop agent is not resumed when a background exec session completes #42908
Description
Product
Codex desktop agent invoking Codex CLI through a long-running exec/PTY session.
Problem
When an exec command yields a session ID and continues in the background, completion is not delivered back to the parent agent as an event. The parent can discover completion only by explicitly polling the session. If the conversational turn has already ended, the workflow cannot automatically resume and run its next step.
Reproduction
- From a Codex desktop task, start a long-running command such as codex exec.
- Let the command yield a PTY/session ID while it keeps running.
- End or yield the parent turn.
- Allow the child process to finish.
Actual behavior
No completion event wakes or resumes the parent task. The result remains undiscovered until the user sends another message or the agent manually polls the PTY session.
Expected behavior
The parent task should receive a terminal-session completion event containing at least the session ID, exit status, and an output cursor. It should then be able to continue the workflow, similar to completion notifications from managed subagents.
Impact
Long-running CLI orchestration requires busy polling or user reminders. Multi-stage flows such as generate, review, and package cannot reliably proceed unattended.
Environment
- Codex CLI 0.153.4
- macOS
- Codex desktop task using an exec/PTY tool
A completion callback from the app-server or desktop terminal-session layer would address this without requiring output polling.
Activity
PHPCraftdream commentedon Sep 24, 2026
Confirmed on Windows with codex-cli 0.156.1 in the ChatGPT desktop app.
Minimal reproduction
Start-Sleep -Seconds 20; Write-Output "ok"throughexec_commandwith a 10-second yield. The tool returns a livesession_id.write_stdin/wait.This also affects CLI orchestration. We ran
rush runin a background terminal and needed the parent agent to verify its result after exit. Polling or a blocking wait keeps the agent occupied; simply ending the turn leaves it asleep.Workaround tested here: attach a
rush run --on-finishhook that callscodex queue --thread <thread-id> --message rush_done:<session-id>. The queued marker woke the active desktop thread automatically in two short runs. We also used a watcher to wake the thread when a previously launched 20-minuterushrun completed. The workaround requires an external CLI call, presents the event as a user message rather than a typed tool event, andcodex queuemay leave it pending if the thread has been unloaded.Expected: background terminal completion should be delivered as a typed event with session ID, exit status, and access to final output. If the agent's turn is idle, the harness should resume it at a safe boundary without model-driven polling, while the user can keep chatting and other commands can run. This would also address the repeated polling cost reported in #45974.
Request: please implement native, event-driven wake-up when a background
exec_commandsession exits. The agent should be able to finish its turn, leave the chat usable, and automatically resume on that process-completion event. Please deliver the result as a tool/terminal event rather than a synthetic user message; nowrite_stdinpolling, blocking wait, orcodex queueworkaround should be required.docs: explain temporary cli-run workaround (openai/codex#42908, opena…
PHPCraftdream commentedon Oct 1, 2026
Following up on my Windows reproduction above: the external
rush --on-finish/codex queueapproach is now available as an installablecli-runMCP integration in my cc-arch-hands package. This is a temporary way to continue command-based workflows while the native desktop completion event requested here is still missing, not a claim that Codex itself has been fixed.The change from the earlier manual wrapper is that Codex can submit a named group of commands to the MCP
runtool. In queue mode, the server starts a detached worker, returns the assigned UID, and obtains the destination thread from Codex's tool-call metadata. The parent can finish its turn while the commands continue. When the group finishes, the worker saves each command's exit code and log and callscodex queueonce with a short success/failure summary. The parent can then retrieve the result withstatusorlogsinstead of keeping an exec/PTY session alive through polling.To install the optional Codex skills and local MCP registration:
Restart Codex to load the server. Installation also adds a marked instruction section for using this path for long-running commands; unrelated user instructions and configuration are preserved.
One distinction matters for the tests: the idle-thread wakeup evidence remains the Windows/Codex 0.156.1 experiment in my previous comment. We separately smoke-tested the current MCP integration on Codex daemon 0.159.3, including inline command completion and preserving an explicit approval policy through reinstall. That latter check is not an additional proof of every desktop idle-wakeup scenario.
This cannot attach to an already-running native
session_id. Queue submission can fail or remain pending when the target thread is unavailable; saved results remain available and the delivery error is recorded. Inline delivery is another mode for a caller that needs the result in the open MCP call, but it does not wake an idle thread. Also, the MCP worker is outside Codex's per-turn filesystem sandbox: permitting arbitraryruncommands requires approval or a deliberate trust choice, not an automatic grant.Usage and the precise issue-coverage table. I still prefer the typed terminal completion event described in this issue over an external helper injecting a queue message.