[Bug]: Claude steers abort automatic context compaction#25796

opened3d agobySstickerdaniel

Before submitting

  • I searched existing issues and did not find a duplicate of this Claude adapter failure.
  • I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

  1. Run a long Claude thread that receives messages from other threads through t3_thread_send with mode: "steer".
  2. Let the receiving thread reach automatic context compaction.
  3. Send a steer while its timeline shows "Compacting context". Repeat while compaction is running.

I also reproduced the failure directly with @anthropic-ai/claude-agent-sdk 0.3.276 and Claude Code 2.1.310: offer a user message with priority: "now" when the output stream reports system/status: compacting. The synthetic reproduction used Sonnet 5.5 and a lowered automatic-compaction threshold.

Expected behavior

Hold steers while automatic compaction is running. Once compaction finishes and the opening prompt is ready, deliver waiting messages together, in order, to the same active T3 turn rather than waiting for that entire turn to finish. Explicit Stop should still cancel undelivered input.

Please confirm this intended behavior during triage. The proposed fix also needs to preserve message outcomes and delegated-delivery acknowledgments when the turn stops or is replaced.

Actual behavior

ClaudeAdapterV2.steerTurn offers the message immediately with priority: "now". Claude aborts compaction, returns an aborted_streaming segment, and starts compacting again. Frequent reports to a coordinator can repeatedly restart compaction.

In one observed thread, 11 compactions ended with aborted, each 39–94 ms after a steer arrived. Other independent compaction/server failures also occurred; this report does not attribute those failures to steering.

Impact

Major degradation or frequent failure

Version or commit

T3 Code 0.1.3-nightly.20261024.3643; Claude Code 2.1.310; Agent SDK 0.3.276.

Environment

macOS 27.0, T3 Code desktop Nightly, Claude provider.

Logs or stack traces

Minimal synthetic reproduction, with message contents and identifiers omitted:

text
1status {"status":"compacting"}
2OFFER priority=now
3status {"status":null,"compact_result":"failed","compact_error":"aborted"} // 6 ms later
4RESULT {"subtype":"success","terminal_reason":"aborted_streaming"}
5status {"status":"compacting"} // starts over

Workaround

Avoid steering while compaction is running. Queueing avoids this interruption but delays the input until the entire active turn ends, so it does not provide the expected in-turn steering behavior.

Related

  • #24137 describes composer follow-ups being queued during automatic compaction; #24138 changes that client behavior. This report concerns the Claude server-side delivery path, already reachable through MCP.
  • #22552 addresses steers overtaking the opening prompt, a related delivery boundary.
  • #24842 concerns request/compaction phases that never progress. A general watchdog is outside this report.
Synced from GitHub

Also hit on a newer nightly, via cross-thread steers from delegated agents (not a composer steer).

  • Receiving thread was compacting automatically. Two steers from other threads (t3_thread_send, steer mode) arrived during compaction.
  • Each one showed "Context compaction failed: aborted" right after it landed, then "Compacting context" started again.
  • The steers were delivered, but the compaction restarted each time. With several agents reporting to one coordinator, this can loop.

Environment: T3 Code 0.1.4-nightly.20261027.3796 (server on Linux, t3 serve), Claude Code 2.1.312, Claude provider.

Agree with the expected behavior in the report: hold steers during compaction, then deliver them together into the same turn.