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

    enhancementNew feature or requestsubagentIssues involving subagents or multi-agent features

    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