[Bug]: Pi: a message sent while Pi is compacting is rejected and lost instead of held until compaction ends #24227

Before submitting

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

Area

apps/server

Steps to reproduce

1. Use a Pi provider thread (Pi 1.4.0).
2. Let Pi start a context compaction that T3 does not own as a running turn, for example an automatic or extension-started compaction right after Pi emits agent_settled (packages/provider-pi/src/server/adapter.ts:371 documents that this can happen).
3. While the compaction is still running, send a new message from the composer.

The existing adapter test reproduces this deterministically against the fake Pi:
packages/provider-pi/src/server/adapter.test.ts:694, "retains native wake ownership after a rejected joining prompt, compaction aborted=%s".

Expected behavior

T3 holds the message and sends it once Pi reports compaction_end, the same way a follow-up sent during a running turn is queued instead of failing. The user should not have to watch for the compaction to finish and then type the message again.

Actual behavior

The turn fails with Pi's error and the message is not delivered:

Cannot submit a prompt while compaction is in progress. Wait for compaction to finish and retry.

Pi rejects every prompt while compaction is running, before it reads streamingBehavior (@earendil-works/pi-coding-agent 1.4.0, dist/core/agent-session.js:1648-1652). Sending turn-start prompts with streamingBehavior: "steer" (#18639) avoids "Agent is already processing", but it does not get past this check.

In the adapter (main @ e340aae):

• A turn-start prompt that Pi rejects becomes the turn's failure (adapter.ts:2013-2030). If T3 adopted a native wake, it records the rejection as rejectedPromptFailure and reports it once Pi settles (adapter.ts:1515). The prompt is never sent again. The test at adapter.test.ts:694 expects this outcome for both a cancelled and a finished compaction: turn.terminal with status: "failed" and the rejection message.
• A steer that Pi rejects only produces a log warning (adapter.ts:2004-2011, "Pi rejected a steer message."). The message is dropped without any error shown in the thread.

The adapter already tracks compaction (activeCompaction, compaction_start/compaction_end at adapter.ts:1780-1834), and Pi reports isCompacting in get_state. So the adapter has the signals it would need to hold a prompt until compaction ends.

Impact

Major degradation or frequent failure

Version or commit

T3 Code Nightly 0.1.3-nightly.20261023.3579 (66ee628)

Environment

macOS 27.0.1, T3 Code desktop (Nightly), Pi 1.4.0 (@earendil-works/pi-coding-agent)

Logs or stack traces

Cannot submit a prompt while compaction is in progress. Wait for compaction to finish and retry.

Workaround

Wait until the compaction has visibly finished, then send the message again.

Related

• [Bug]: Follow-ups queue instead of steering during automatic compaction #24137 covers Codex/Claude, where the web client queues instead of steering during automatic compaction. That is a different provider path and close to the opposite symptom.
• fix(pi): queue turn-start prompts when native work is running #18639 fixed the same kind of rejection for "Agent is already processing", but not for compaction.