What version of Codex CLI is running?
codex-cli 0.115.0
What subscription do you have?
Unknown / source-level investigation
Which model were you using?
N/A (source-level investigation)
What platform is your computer?
Darwin 25.3.0 arm64 arm
What terminal emulator and version are you using (if applicable)?
ghostty
What issue are you seeing?
During a source-level investigation of Codex multi-agent behavior, I found that close_agent returns the receiver's status before shutdown is requested, not the final post-close state.
This appears to be intentional in the current implementation, but it is very easy for callers and workflow authors to misread.
Relevant source references:
codex-rs/core/src/tools/handlers/multi_agents/close_agent.rs
- handler reads current status first via
subscribe_status(...).borrow_and_update(): lines around 45-52
- then sends shutdown: lines around
71-78
- then returns the earlier status: line around
98
codex-rs/core/src/tools/spec.rs
- tool description says:
Close an agent when it is no longer needed and return its last known status.
codex-rs/core/src/tools/handlers/multi_agents_tests.rs
- test explicitly asserts
result.status == status_before
The behavior is therefore consistent with the code and tests, but the API shape is easy to misuse when orchestrating subagents.
I searched for similar issues before opening this one and did not find a direct match for this close_agent status semantic.
What steps can reproduce the bug?
A minimal repro is:
- Spawn an agent.
- Call
close_agent on that agent while it is not already in Shutdown state.
- Observe that the returned payload contains the previous status.
- Observe separately that the actual shutdown/not-found transition happens later via status updates or notifications.
In code terms:
close_agent subscribes to status and snapshots the current value.
close_agent then requests shutdown.
close_agent returns the status captured before the shutdown transition completed.
What is the expected behavior?
One of the following would be clearer:
- return the final closed state (
Shutdown or NotFound) after waiting for it, or
- keep the current behavior but rename the returned field to something like
previous_status, or
- return both values, e.g.
{ previous_status, shutdown_requested }.
The important part is making it harder to mistake the return value for the final closure state.
Additional information
This seems more like an API/UX semantic issue than a crash bug, but it has practical impact on multi-agent orchestration:
- workflow authors can incorrectly treat
close_agent as a completion barrier
- callers can think the agent is fully shut down when the returned status still says
running, completed, etc.
- the true terminal state may only be visible later through notifications or subsequent status checks
What version of Codex CLI is running?
codex-cli 0.115.0
What subscription do you have?
Unknown / source-level investigation
Which model were you using?
N/A (source-level investigation)
What platform is your computer?
Darwin 25.3.0 arm64 arm
What terminal emulator and version are you using (if applicable)?
ghostty
What issue are you seeing?
During a source-level investigation of Codex multi-agent behavior, I found that
close_agentreturns the receiver's status before shutdown is requested, not the final post-close state.This appears to be intentional in the current implementation, but it is very easy for callers and workflow authors to misread.
Relevant source references:
codex-rs/core/src/tools/handlers/multi_agents/close_agent.rssubscribe_status(...).borrow_and_update(): lines around45-5271-7898codex-rs/core/src/tools/spec.rsClose an agent when it is no longer needed and return its last known status.codex-rs/core/src/tools/handlers/multi_agents_tests.rsresult.status == status_beforeThe behavior is therefore consistent with the code and tests, but the API shape is easy to misuse when orchestrating subagents.
I searched for similar issues before opening this one and did not find a direct match for this
close_agentstatus semantic.What steps can reproduce the bug?
A minimal repro is:
close_agenton that agent while it is not already inShutdownstate.In code terms:
close_agentsubscribes to status and snapshots the current value.close_agentthen requests shutdown.close_agentreturns the status captured before the shutdown transition completed.What is the expected behavior?
One of the following would be clearer:
ShutdownorNotFound) after waiting for it, orprevious_status, or{ previous_status, shutdown_requested }.The important part is making it harder to mistake the return value for the final closure state.
Additional information
This seems more like an API/UX semantic issue than a crash bug, but it has practical impact on multi-agent orchestration:
close_agentas a completion barrierrunning,completed, etc.