[Bug]: Pi turn-start prompt lacks streamingBehavior — pi 1.0.x rejects prompts while an agent run is active
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 84/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- typescript
Research direction
Start in apps/server/src/orchestration-v2/Adapters/PiAdapterV2.ts at the turn-start prompt around lines 2358-2362, and compare it with the steer path around line 2444 and its streamingBehavior comment. Ensure the turn-start request handles an active Pi run, then verify that the affected thread starts successfully while extension-driven work is in flight.
Written by the indexing model from the issue text.
Description
Area: apps/server
Steps to reproduce
- Install pi ≥ 1.0.0 (observed on 1.0.0 and 1.0.1;
npm i -g @earendil-works/pi-coding-agentor bun global) and enable the Pi provider. - Have a pi session whose extension state triggers a run on resume — e.g. a pi-loop extension iteration waiting on a monitor event, or any pending extension continuation. (Observed: session last ended mid-run, so the resumed session re-fires work immediately after
switch_session.) - Open a T3 thread bound to that session and send a message.
T3's turn-start prompt races the extension-driven run:
→ {"type":"switch_session","sessionPath":"…/session.jsonl","id":"t3-0"}
→ {"type":"get_commands","id":"t3-1"}
→ {"type":"get_state","id":"t3-2"}
→ {"type":"get_available_models","id":"t3-3"}
→ {"type":"get_entries","id":"t3-4"}
→ {"type":"set_model",…,"id":"t3-5"}
→ {"type":"set_session_name",…,"id":"t3-6"}
→ {"type":"prompt","message":"Context handoff (delta_since_target_last_seen):…"}
← {"type":"response","command":"prompt","success":false,"error":"Agent is already processing. Specify streamingBehavior ('steer' or 'followUp') to queue the message."}
Expected behavior
The turn starts. Since pi 1.0.x, AgentSession.prompt() rejects a bare prompt while a run is active — agent-session.ts:1965-1970 at tag v1.0.1:
// If streaming, queue via steer() or followUp() based on option
if (this.isStreaming) {
if (!options?.streamingBehavior) {
throw new Error(
"Agent is already processing. Specify streamingBehavior ('steer' or 'followUp') to queue the message.",
);
}
So the turn-start prompt must either pass streamingBehavior (pi's steer semantics queue it atomically during an active run) or T3 should check get_state and abort the active run before prompting.
Actual behavior
The prompt is rejected and the user sees:
Provider error: Agent is already processing. Specify streamingBehavior ('steer' or 'followUp') to queue the message.
The turn never starts; the session is left in an error state. Every retry while an extension-driven run is in flight bounces the same way, so the thread is effectively unusable.
Impact
Blocks work completely (for the affected thread). Workaround exists but is costly — see below.
Version or commit
0.0.46-nightly.20261003.2632 (f391794a35c6). Defect present at current main (ce90eec1): turn-start sends a bare prompt at apps/server/src/orchestration-v2/Adapters/PiAdapterV2.ts:2358-2362 while the steer path (line 2444) already passes streamingBehavior: "steer" — its own comment (line 2421) documents pi's queue-or-run semantics:
Prompt with streamingBehavior steer is atomic on Pi's side: it queues during an active run and starts a new run if settlement won the race.
Environment
macOS 27.0.1 (arm64), T3 Code desktop (Nightly), pi @earendil-works/pi-coding-agent 1.0.1 (bun global install; behavior identical on 1.0.0), Node v26.9.0.
Related
#13507 / #13839 cover extension-driven session rewinds and their ref/rollback reconciliation — a different mechanism. This report is about the prompt contract itself: pi 1.0.x made bare prompt throw while a run is active, and T3's turn-start path (tested against pi 0.8x, cf. #13839's verification against pi 0.87.1) hasn't caught up. Both are part of the same theme: extensions drive pi sessions in ways the adapter's request paths don't fully anticipate.
Logs or stack traces
ProviderAdapterEventStreamError: Failed while streaming pi provider session provider-session:provider-instance:pi:thread:…:… events.
at orchestrationV2.providerTurnStart.start (apps/server/dist/binCli-D9mHsJrM.mjs:228797)
[cause]: Error: Cause([Fail(PiRpcError: Pi RPC read failed: pi process exited with code 0.)])
RPC capture (tee on pi stdin/stdout) of the rejected exchange and the extension-driven runs that follow — full transcript available on request. Redacted: session paths truncated; no secrets in the capture.
Workaround
Setting the Pi provider's Launch arguments to --no-extensions stops extension-discovery extensions (pi-lens, pi-loop, …) from loading in T3 sessions — T3's own --extension still loads — which removes the busy-at-load races. Cost: pi-lens features are unavailable in T3 sessions. Alternatively wait for extension-driven runs to settle before prompting.
Minor side note
A bare 1.0.1 (version string) line appears on pi's stdout in RPC mode — most likely pi's own version/update-check output landing on the protocol channel. T3 drops non-JSON lines so it's harmless, but raw prints on the RPC channel would be worth avoiding.
- Dominant language
- TypeScript
- Stars
- 24.4k
- Forks
- 6.4k
- Avg merge
- 10h 48m
- Merged PRs (30d)
- 215
Getting set up
Starts the project's dev container in your browser, under your own GitHub account.
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from pingdotgg/t3code
-
bug via-triage
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
pingdotgg/t3code#15161 · 1 comment ·
Maintainers usually reply within 1 day
-
bug good first issue via-triage
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
pingdotgg/t3code#15159 · 1 comment ·
Maintainers usually reply within 1 day
-
bug via-triage
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
pingdotgg/t3code#15146 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Maintainers usually reply within 1 day
-
bug needs-triage
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
All issues in pingdotgg/t3code
Similar issues
-
keytrace logo svg?Open
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
cyclofinance/cyclo.site#448 ·
-
[sanity-plugin-media] Searching for a word with an apostrophe shows an error instead of resultsOpen@sanity-io/studio bug sanity-plugin-media Sieve-Agent
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
accessibility
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
slovensko-digital/priznanie-digital#1188 ·
Maintainers usually reply within 1 day