SessionStart source=clear does not fire until the first prompt after /clear

Resolved 💬 2 comments Opened Jun 1, 2026 by andresbernasconi Closed Jun 5, 2026

When running /clear in Codex CLI, SessionStart hooks for source=clear do not appear to fire at the moment the clear command is executed. The new session state is only observed after the next real user prompt is submitted. At that point, Codex reports a new session_id and emits SessionStart close to UserPromptSubmit.

Observed on codex-cli 0.128.0:

  1. Existing Codex session is idle with session id 019e7418-cdfc-7371-8e42-605b10afb493.
  2. User enters /clear.
  3. No SessionStart hook is observed for that tab/session.
  4. The observed session id remains 019e7418-cdfc-7371-8e42-605b10afb493.
  5. User submits a normal prompt: Hello.
  6. Only then Codex reports a session id change to 019e8440-5132-7813-a319-576b3c0c806a.
  7. SessionStart and UserPromptSubmit hooks are then observed around the same prompt submission.

Expected: running /clear should emit an immediate hook signal that clients can observe, ideally SessionStart with source=clear, or another explicit slash-command/session-reset event.

Why this matters: hook-only terminal hosts cannot distinguish an idle unchanged session after /clear from an idle unchanged session where no clear happened. The only reliable way to update immediately would be to intercept terminal input and detect /clear, which defeats hook-only integration.

Related: #15266, #15269, and the broader hook parity tracker #21753.

Environment: Codex CLI 0.128.0, macOS, zsh, hook-only terminal host integration.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗