fix(codex_app_server): make /stop actually stop the codex turn

[h4x3rotab]

Summary

Two related bugs in the codex_app_server interrupt path. Net effect today: `/stop` (and any gateway-side cancellation) does nothing on the codex_app_server runtime for up to 10 minutes, and the session lifecycle has races around the few interrupt paths that do work.

Bug 1 — `AIAgent.interrupt()` never propagated to the codex session

`CodexAppServerSession.request_interrupt()` is the public API for signalling the run-turn loop to bail. Tests call it; production never does. Grep:

```
$ grep -rn 'request_interrupt' --include='*.py' | grep -v test_ | grep -v pycache
agent/transports/codex_app_server_session.py:315: def request_interrupt(self) -> None:
```

Zero production callers. So when a user hits `/stop` (or the gateway cancels a Telegram conversation, etc.), `AIAgent.interrupt()` flips `self._interrupt_requested = True`, fans out signals to worker threads, walks child agents — but the codex subprocess never sees any of it. The turn runs until one of:

• post-tool quiet watchdog (90 s after a tool completion)
• outer deadline (600 s default)

That's the user-visible "stop doesn't stop" symptom on this runtime.

Fix: in `AIAgent.interrupt()`, after the existing fan-out, also call `self._codex_session.request_interrupt()` when a session is attached. The session's run-turn loop already checks `_interrupt_event` at the top of every iteration and issues `turn/interrupt` to codex when it sees it — we just had to wake it up.

Bug 2 — User interrupt + `<turn_aborted>` left `should_retire=False`

Three out of four "we're done early" paths set `result.should_retire = True`:

line	trigger	sets `should_retire`?
451	`_interrupt_event.is_set()` (user/gateway)	no ← bug
481	post-tool quiet watchdog	yes
567 / 510	`<turn_aborted>` marker	no ← bug
605	outer deadline	yes

The runtime caller in `agent/codex_runtime.py:98` only closes the session when `should_retire` is True. So a user-interrupted turn (or a `<turn_aborted>` one) leaves the codex subprocess alive while it's presumably still cleaning up the interrupted turn. The next `turn/start` races against that cleanup.

Fix: set `result.should_retire = True` on the user-interrupt path (1 line) and both `<turn_aborted>` paths (1 line each). Matches the existing post-tool and deadline behaviour.

Test plan

`tests/run_agent/test_interrupt_codex_session.py` (new, 4 tests):

• propagation fires `request_interrupt()` exactly once when a session is attached
• no-op when `_codex_session` attribute doesn't exist (default runtime / pre-first-turn)
• a throwing `request_interrupt()` doesn't break the rest of the interrupt flow
• `_codex_session = None` (post-retire) is handled cleanly

`tests/agent/transports/test_codex_app_server_session.py: TestSessionRetirement` (2 new tests):

• user interrupt → `should_retire is True`
• `<turn_aborted>` in agentMessage text → `should_retire is True`

`pytest tests/agent/transports/test_codex_app_server_session.py tests/run_agent/test_interrupt_codex_session.py tests/run_agent/test_concurrent_interrupt.py tests/run_agent/test_memory_sync_interrupted.py` → 81/81 pass (5 new + 76 pre-existing, no regressions).

Smaller follow-ups not in scope

These came up during the audit but aren't broken behaviour, just suboptimal:

• The interrupt RPC blocks up to 5 s with codex wedged. Could lower the timeout or fire-and-forget.
• The approval-drain loop doesn't check `_interrupt_event`. Sub-second window, low impact.
• The drain-loop `<turn_aborted>` branch doesn't carry over `result.final_text` (the normal-loop sibling does). Cosmetic.

Happy to tackle these in a follow-up PR if you want.

🤖 Generated with Claude Code