[Sugamsss]

Grok follow-ups currently interrupt and restart the active prompt, cancelling tools the user asked to keep running. This queues them through T3's existing durable queue instead, retaining normal image and file attachments.

Closes #27014.

Change

Override only Grok's supportsSteeringByInterruptRestart capability to false, following the provider-specific fallback used for Copilot in #26715. Shared command policy already queues automatic and explicit Steer follow-ups when neither steering path is safe. No shared production policy, client, contract, hook, or Grok binary changes.

This is queueing, not native mid-turn steering. Grok already supports _x.ai/interject, including structured image content, but merely wiring it up does not handle its completion race: an interjection arriving after the intended prompt ends can start native fallback work outside the current T3 turn. #27014 records that separate lifecycle boundary. This PR prevents destructive follow-ups without adding a text-only hook workaround or a new attachment limit.

Behavior and limits

• Current tools finish normally; the follow-up starts after the current turn completes.
• Images and file attachment identity are retained through the existing queue; native transport was also checked below.
• Stop stays available and its implementation is unchanged.
• Explicit Restart becomes unsupported for Grok, including through t3_thread_send, because the existing restart policy uses the same capability. Use Stop, then send a new message when cancellation is intended. User docs disclose this.
• Does not fix held roots/background-subagent lifecycle (fix(provider-acp): Grok runs finish with their reply while background subagents keep working #17779). A turn that never completes can still hold queued work.
• Other providers' production code is unchanged.

Scope / contribution policy

No maintainer approval has been given on #27014. I am submitting this under the very-small focused obvious-bug exception: the defect is cancellation of ongoing work by a follow-up, and the production change is a Grok-only capability override using an existing, merged fallback. I recognize that maintainers may still require prior product-direction discussion because Steer and explicit Restart behavior change. I am not treating the issue or Copilot precedent as approval.

Verification

Regression tests failed before the production change: Grok policy selected steering, forced Restart succeeded, and the orchestration regression observed an interrupt of the original provider turn. After the override:

• vp test run apps/server/src/orchestration-v2/CommandPolicy.test.ts apps/server/src/orchestration-v2/SteeringCompletion.integration.test.ts apps/server/src/orchestration-v2/Adapters/GrokAdapterV2.test.ts: 46 passed, rerun on final branch rebased onto 960d5761c13f.
• Independent review reran those 46 cases and the existing Copilot capability regression: 1 passed. No correctness blockers found.
• vp run check:changed: passed on the final rebased commit, exactly four PR files. Format, lint, both knip passes, GraphQL generation, 10 affected package typechecks, and 37 selected tests passed. Nine of ten typecheck tasks reused cache.
• Existing orchestration coverage now uses actual Grok flavor capabilities and asserts queueing, zero steering/interruption, original run remaining active, one later delivery, and retained image/file attachments. Tests use event subscriptions and effect-worker drains, not timing sleeps.

Native runtime transcript

macOS arm64, Grok Build 1.0.70 (f50904eaee6c), configured custom-gateway Luna model. Actual Grok adapter/ACP runtime plus the orchestration harness and in-memory database; temporary workspace, attachment state and isolated GROK_HOME. No live T3 database or installed application modifications.

First prompt ran a foreground sleep 12; echo FOREGROUND_DONE. Follow-up with a PNG and text-file attachment was sent at the tool-running milestone:

2026-10-29 UTC
16:12:05.289  native prompt started #1
16:12:08.184  foreground tool running
16:12:08.190  follow-up status=queued; first=running
16:12:20.320  foreground tool completed
16:12:20.321  exit=0; FOREGROUND_DONE present
16:12:23.506  native prompt started #2
16:12:26.196  cancels=0; prompts=2;
              imageBytesDelivered=true; filePathDelivered=true; attachmentCount=2

The logger compared image bytes and the resolved file path without publishing their contents. This establishes attachment transport, not semantic image understanding or file reading. Native runtime exercise covers after; the failing source-state regressions establish before. No browser/mobile UI run or additional real Stop exercise was performed; this is a server/provider-only change and existing Stop code is untouched.

Implemented and reviewed with Codex GPT-6.1 Sol through T3 Code; final review and submission with Claude Code.

🤖 Generated with Claude Code

[Sugamsss]

Additional final verification on head fd3e3ef:

• Reviewed every changed line and traced capability consumers through message dispatch, explicit Restart, Stop, and client queue-promotion behavior. No further code changes needed.
• Ran the policy, steering integration, Grok adapter, ACP registry/Copilot, and client thread-workflow suites: 83 tests passed across 5 files.
• Ran the server package vp run build:bundle: passed.
• Negative control: temporarily restored Grok interrupt/restart capability. The targeted regressions failed: policy selected steer_active and the orchestration test recorded interruption of the original turn. Restored the fix; all 6 selected cases passed. The working tree has no tracked changes afterward.

This remains a focused safe-queue fallback, not native mid-turn interjection. Explicit Restart is unsupported and held roots can still delay queued messages, as documented in the PR.

[Sugamsss]

Ready for maintainer review at fd3e3ef. The branch is conflict-free against current main, maintainer edits are enabled, 83 targeted tests and the server bundle build pass locally, and the regressions fail when the Grok-only capability override is removed.

The upstream CI run is currently action_required with no jobs started: https://github.com/pingdotgg/t3code/actions/runs/40911269423. Could a maintainer approve the workflow run and confirm whether this focused reliability fix is acceptable? Macroscope also skipped because of the existing unvouched-contributor policy; I have not attempted to change that label or bypass review.

The scope decision is explicit: use the existing attachment-capable queue instead of interrupting running Grok tools; Stop remains supported, while explicit Restart becomes unsupported. Native mid-turn interjection and held-root/background lifecycle changes remain out of scope. Happy to address concrete review findings or adjust to the preferred scope.

[coderabbitai]

No actionable comments were generated in the recent review.

Recent review info

Run configuration

• Source mode: Auto
• Repository: pingdotgg/t3code
• Branch: main
• File: .coderabbit.config.ts
• Commit: 960d576
• Layers: Repository TS config
• Review profile: CHILL
• Plan: Advanced
• Run ID: 1687f60e-81b5-4ca0-bffe-cd82c7a86d18

Commits

Reviewing files that changed from the base of the PR and between 960d576 and fd3e3ef.

Files selected for processing: 4

• apps/server/src/orchestration-v2/CommandPolicy.test.ts
• apps/server/src/orchestration-v2/SteeringCompletion.integration.test.ts
• docs/user/composer.md
• packages/provider-grok/src/server/adapter.ts

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 9 remain after this review.

Walkthrough

Grok now disables interrupt-and-restart steering, so follow-up messages use the queue path when steering is unsupported. Tests cover policy behavior and retention of image and pasted-text attachments. Composer documentation explains how Grok handles follow-ups, Stop, and Restart.

Changes: Grok follow-up delivery

Layer / File(s)	Summary
Grok steering capability and policy packages/provider-grok/src/server/adapter.ts, apps/server/src/orchestration-v2/CommandPolicy.test.ts	Grok’s turn capabilities now disable interrupt-and-restart steering. Policy tests cover queued steering and verify that forced restart is rejected with the interrupt_restart_steering capability error.
Queued follow-ups and attachments apps/server/src/orchestration-v2/SteeringCompletion.integration.test.ts, docs/user/composer.md	The integration test checks that image and pasted-text attachments remain on a queued Grok follow-up when its turn starts, and that no steering call occurs. The composer docs state that follow-ups wait for the current turn, Stop cancels current work, and explicit Restart is unsupported.

Priority: Normal

Estimated code review effort: 2 (Simple) | ~12 minutes

Severity of issue fixed: Medium

Possibly related PRs

• pingdotgg/t3code#26715: Adds the capability-based queueing path that this change uses for Grok follow-ups.
• pingdotgg/t3code#25944: Exposes queue, auto, steer, and restart delivery modes through t3 thread send; this change affects Grok’s policy for those modes.
• pingdotgg/t3code#24653: Addresses follow-ups during active foreground tools for Claude, using a different provider-specific approach.

Suggested reviewers: maria-rcks, shivamhwp, juliusmarminge

Merge Risk: Minimal · up to fd3e3

Grok follow-ups wait for the current turn. No merge-blocking issue was established.

Pre-merge checks: 4

Check name	Status	Explanation
Title check		The title clearly and concisely describes the main change: Grok follow-ups are queued instead of interrupting active tools.
Description check		The description is complete. It explains the problem, implementation, behavior limits, scope justification, verification results, runtime evidence, and known gaps.
Linked Issues check		The PR addresses the active coding requirements in #27014. packages/provider-grok/src/server/adapter.ts sets Grok supportsSteeringByInterruptRestart to false, so the existing policy selects the …
Out of Scope Changes check		The changed files stay within #27014. The production change is a Grok-only capability override. The policy and orchestration changes add regression coverage for queue selection, attachment retention, …

Full details: Linked Issues check

Explanation

The PR addresses the active coding requirements in #27014. packages/provider-grok/src/server/adapter.ts sets Grok supportsSteeringByInterruptRestart to false, so the existing policy selects the durable queue instead of interrupt/restart steering. The policy tests cover automatic and explicit Steer delivery, Grok Stop permission, and rejection of explicit Restart. The orchestration integration test covers queued delivery with image and file attachments. The existing Stop implementation remains unchanged. The documentation discloses queued behavior and unsupported Grok Restart behavior. The issue permits this queueing fallback when native steering is not lifecycle-safe.

Full details: Out of Scope Changes check

Explanation

The changed files stay within #27014. The production change is a Grok-only capability override. The policy and orchestration changes add regression coverage for queue selection, attachment retention, and Restart behavior. The documentation describes the changed user behavior. No shared production policy, other provider, client, contract, hook, or native Grok interjection changes are included.

Finishing Touches

🧪 Generate unit tests (beta)

• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

_{Comment @coderabbitai help to get the list of available commands.}

[Sugamsss]

Marking this PR as draft while reconsidering the direction. The requested outcome is native mid-turn Grok steering, including images, not merely queueing until the turn ends. This patch is a cancellation mitigation and should not be presented as implementing that outcome.

Installed Grok ACP interjection worked in our live foreground-tool test. The remaining native-integration question is lifecycle ownership when interjection races prompt completion: a late native fallback prompt must remain tracked and reachable by Stop, with no duplicate delivery. That boundary needs addressing rather than assuming queueing is the final solution. The current code remains the queue-only mitigation; no native steering implementation has been pushed.