Remote-control agent sessions cannot be stopped from codex agents
Open 💬 2 comments Opened Aug 25, 2026 by jam35L
💡 Likely answer: A maintainer (github-actions[bot], contributor)
responded on this thread — see the highlighted reply below.
Summary
When Remote Control is enabled, sessions started through Remote Control remain ready and selectable in codex agents, but cannot be ended from the UI.
Environment
- Codex CLI: 0.149.1
- macOS
- Shared local app-server daemon started with Remote Control enabled
Steps to reproduce
- Start the local daemon with Remote Control enabled and start an agent/session through Remote Control.
- Run
codex agents. - Select a ready agent other than the one to retain.
- Try the advertised
Ctrl-Xaction shown in the footer asctrl+x stop. - Also try entering the session and using
Ctrl-C,d, or/exit.
Actual behavior
Ctrl-Xdoes nothing: the selection remains and the agent/session stays ready and selectable.Ctrl-C,d, and/exitdo not terminate the session/agent.- The session therefore appears unkillable through either the session UI or the agent command center.
Expected behavior
The documented Ctrl-X action should explicitly stop/end the selected agent, remove it from the active agent list, and cancel any active turn without affecting other agents or the shared Remote Control daemon.
Workaround
codex archive <session-id> removes a ready session from the active list, but it is a reversible archive operation rather than a true stop/cancel mechanism. It is not an adequate workaround for a working agent.
I reproduced the non-functional Ctrl-X behavior locally while preserving another working session.
2 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
The
ctrl-xaction stops the current turn. It does not unload the session. Sessions are unloaded only after 30 minutes of no activity and after all clients have unsubscribed from them. If you have a remote session running, that client will be subscribed to it, which keeps it loaded. There's currently no mechanism in the app server to negotiate with all subscribed clients to get them to unsubscribe from a session, and forcibly unsubscribing them is probably not desirable.