Real T3 Code server, Grok CLI 1.0.77 (50ca579fa996), hub model claude-haiku-5-5, full-access runtime.
Base: 48cdefed5ae38a76cd10affc112a2c96e882df04. Head: 8132c75ba1cf1c9f1f5670578ca0c4b8ab05dec1.
Each checkout started with T3CODE_DEV_SEED=0, a fresh database, and only synthetic project/thread data.
Two identical harness adjustments match triage: CLI sends mode=steer rather than hard-coded queue; the ACP auth advertisement guard allows xai.api_key, which this Grok accepts but does not advertise. No steering capability code was modified.
The driver observes the foreground Python PID before sending the exact follow-up, then records its survival and reads real server thread messages through the CLI.
Browser: headless Chrome 151, light theme, 1440x900. Published captures crop to the left 1128x900 to exclude machine-only details. Screenshots were byte-identical 500ms apart before selection.
Base first run: tool observed at 22:43:01 UTC, follow-up sent at 22:43:03, response steered at 22:43:05, original process absent then. Assistant reports cancellation, no output, FOLLOWUP_DONE. Before still is this run.
Base video repeat: original PID observed at 22:44:49 UTC, follow-up sent at 22:44:51, steered response and original PID absent at 22:44:52. Grok independently chose to rerun the command; the later marker is from a replacement command. The UI shows Superseded attempt / Cut off by a steer. No reproduction steps were changed.
Head: steer is queued; the original PID survives until its 30-second sleep completes, its output is reported, and the follow-up completes as a second turn with FOLLOWUP_DONE.
Replay scenarios cannot exercise this Grok-specific behavior, as the scenario documentation explains. Preview browser failed under AppArmor; agent-browser fallback provided real browser recordings.
Native interjection, attachments, Stop, desktop shell, and mobile were not exercised. This fix proves the allowed queue fallback.