Skip to content

close_agent returns the pre-close status, which is easy to misread as the final close state #14907

@nantas

Description

@nantas

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:

  1. Spawn an agent.
  2. Call close_agent on that agent while it is not already in Shutdown state.
  3. Observe that the returned payload contains the previous status.
  4. Observe separately that the actual shutdown/not-found transition happens later via status updates or notifications.

In code terms:

  1. close_agent subscribes to status and snapshots the current value.
  2. close_agent then requests shutdown.
  3. 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

Metadata

Metadata

Assignees

No one assigned

    Labels

    agentIssues related to the core agent loopenhancementNew feature or request

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions