feat(providers): add Pi coding agent

[quasarea]

Summary

Adds Pi as a first-class, disabled-by-default coding-agent provider for the Orchestrator V2 architecture.

This is a stacked draft targeting the head branch of #2829 (t3code/codex-turn-mapping); it can be retargeted to main after that PR lands.

• adds a scoped Pi JSONL RPC transport with correlated requests, strict LF framing, process cleanup, and Windows command resolution
• projects Pi streaming text, reasoning, tools, retries, compaction, terminal state, approvals, and user-input requests into Orchestrator V2 events
• persists Pi session identity and resumes existing sessions with switch_session
• discovers account-specific provider/model slugs and exposes Pi's seven thinking levels
• forwards image attachments for prompts and steering
• adds isolated RPC-backed text generation for commit messages, PR content, branch names, and task titles
• registers Pi across provider settings, model selection, web icons, and mobile icons

Why

T3 currently has first-party Codex, Claude, Cursor, Grok, OpenCode, and ACP integrations, but no Orchestrator V2 driver for Pi. Pi's official RPC mode provides the session, streaming, model-selection, tool, and extension UI primitives needed for a native adapter without scraping terminal output.

The implementation intentionally stays inside T3 because the provider, orchestration, settings, and presentation contracts are currently internal. Repository coordination and Forgejo authentication remain outside this driver; Pi can invoke the shared forgejo-bridge CLI through its normal shell tools without duplicating API or credential logic.

User impact

After enabling Pi in provider settings, users can select discovered Pi models, choose supported thinking levels, run persistent coding sessions, resume them after T3 runtime restarts, steer or interrupt active work, answer extension prompts, attach images, and use Pi for T3's generated Git metadata.

Pi remains disabled by default and is marked Early Access.

Intentional limitations

• provider-native conversation rollback and fork are disabled until Pi session entry IDs are projected safely; T3 filesystem checkpoints remain available
• Pi usage is decoded and validated, but Orchestrator V2 does not currently expose a provider usage-accounting event surface
• this branch was validated with deterministic RPC process fixtures because the Pi CLI was not installed on the development host

Validation

• pnpm exec vp test run src/orchestration-v2/Adapters/PiRpcTransport.test.ts src/orchestration-v2/Adapters/PiRpcProtocol.test.ts src/provider/Layers/PiProvider.test.ts src/provider/Drivers/PiDriver.test.ts src/orchestration-v2/Adapters/PiAdapterV2.test.ts src/textGeneration/PiTextGeneration.test.ts — 20 tests passed
• pnpm exec vp test run --project unit src/components/settings/ProviderSettingsForm.test.ts — 13 tests passed
• pnpm exec vp test run src/settings.test.ts — 34 tests passed
• server, web, contracts, and mobile typechecks passed
• focused lint, formatting, and whitespace checks passed

References

• Pi RPC documentation
• Pi SDK documentation

Note

Add Pi coding agent as a new provider with orchestration, text generation, and settings UI

• Introduces the pi provider driver backed by the @earendil-works/pi-coding-agent npm package, disabled by default with binaryPath: 'pi'.
• Adds PiAdapterV2 implementing the full orchestration V2 interface: streaming text/tool events, interrupt/steer, extension UI approvals, thread snapshots, and image attachments via base64 encoding.
• Adds PiTextGeneration for structured RPC-backed generation of thread titles, commit messages, PR content, and branch names.
• Adds PiProvider with CLI health probing, RPC-based model discovery, and thinking-level capability descriptors for reasoning models.
• Registers the provider across contracts (settings schema, display name, model slug aliases), server driver registry, orchestration V2 adapter registry, and web/mobile UI (icon, picker badge, settings form).

📊 Macroscope summarized 5c2ce2b. 16 files reviewed, 0 issues evaluated, 0 issues filtered, 0 comments posted

🗂️ Filtered Issues

No issues evaluated.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 51996517-1b64-46fd-80a9-fc343c40c304

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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

[macroscopeapp]

🟡 Medium Adapters/PiAdapterV2.ts:1019

After startTurn calls set_model, providerSession.model is never updated, so updateSession("running") keeps the model from openSession and providerSession.model misreports the model actually running the turn. Consider updating providerSession.model to turnInput.modelSelection.model before or during updateSession("running") so session snapshots reflect the switch.

              yield* updateThread(state, {
                status: "active",
                firstRunOrdinal: state.providerThread.firstRunOrdinal ?? turnInput.runOrdinal,
              });
-             yield* updateSession("running");
+             yield* updateSession("running", null, turnInput.modelSelection.model);

🤖 Copy this AI Prompt to have your agent fix this:

In file @apps/server/src/orchestration-v2/Adapters/PiAdapterV2.ts around line 1019:

After `startTurn` calls `set_model`, `providerSession.model` is never updated, so `updateSession("running")` keeps the model from `openSession` and `providerSession.model` misreports the model actually running the turn. Consider updating `providerSession.model` to `turnInput.modelSelection.model` before or during `updateSession("running")` so session snapshots reflect the switch.

[macroscopeapp]

🟡 Medium Layers/PiProvider.ts:243

authenticated is derived from the merged models list, which includes settings.customModels via providerModelsFromSettings. When RPC discovery fails or returns no models but the user has configured custom models, the provider is incorrectly reported as ready and authenticated, suppressing the warning that no models are available. Authentication should be determined from the discovered RPC models before merging custom settings.

🤖 Copy this AI Prompt to have your agent fix this:

In file @apps/server/src/provider/Layers/PiProvider.ts around line 243:

`authenticated` is derived from the merged `models` list, which includes `settings.customModels` via `providerModelsFromSettings`. When RPC discovery fails or returns no models but the user has configured custom models, the provider is incorrectly reported as `ready` and `authenticated`, suppressing the warning that no models are available. Authentication should be determined from the discovered RPC models before merging custom settings.

[macroscopeapp]

🟡 Medium Adapters/PiRpcTransport.ts:225

If a request fiber is interrupted after it registers its deferred in pendingRequests but before it completes, the map entry is never removed. A later response for that orphaned id is silently consumed by the abandoned deferred instead of being exposed on messages, and repeated cancelled requests leak entries until transport shutdown. The cleanup at the end of request only runs on normal completion — interruption skips it. Wrap the body in Effect.ensuring(() => Effect.sync(() => pendingRequests.delete(id))) so the entry is removed regardless of how the fiber terminates.

🤖 Copy this AI Prompt to have your agent fix this:

In file @apps/server/src/orchestration-v2/Adapters/PiRpcTransport.ts around line 225:

If a `request` fiber is interrupted after it registers its deferred in `pendingRequests` but before it completes, the map entry is never removed. A later response for that orphaned `id` is silently consumed by the abandoned deferred instead of being exposed on `messages`, and repeated cancelled requests leak entries until transport shutdown. The cleanup at the end of `request` only runs on normal completion — interruption skips it. Wrap the body in `Effect.ensuring(() => Effect.sync(() => pendingRequests.delete(id)))` so the entry is removed regardless of how the fiber terminates.

[macroscopeapp]

🟡 Medium Adapters/PiAdapterV2.ts:572

On tool.completed, emitTool overwrites the tool call's input with {}, so the final turn_item.updated event drops the arguments that were emitted on tool.started/tool.updated. Persisted completed tool calls end up with empty input. This is because projected.args is absent in the completion projection, and the code uses projected.type === "tool.completed" ? {} : projected.args. Track the last emitted args per toolCallId and reuse it on completion instead of resetting to {}.

Suggested change

	const nativeItemId = projected.toolCallId;
	const nativeItemId = projected.toolCallId;
	const lastArgs = turn.toolArgs.get(nativeItemId) ?? projected.args ?? {};
	if (projected.type !== "tool.completed") turn.toolArgs.set(nativeItemId, projected.args ?? {});

🤖 Copy this AI Prompt to have your agent fix this:

In file @apps/server/src/orchestration-v2/Adapters/PiAdapterV2.ts around line 572:

On `tool.completed`, `emitTool` overwrites the tool call's `input` with `{}`, so the final `turn_item.updated` event drops the arguments that were emitted on `tool.started`/`tool.updated`. Persisted completed tool calls end up with empty input. This is because `projected.args` is absent in the completion projection, and the code uses `projected.type === "tool.completed" ? {} : projected.args`. Track the last emitted `args` per `toolCallId` and reuse it on completion instead of resetting to `{}`.

[macroscopeapp]

🟡 Medium Adapters/PiAdapterV2.ts:810

When a Pi turn reaches terminal status, any pending runtime requests (extension UI prompts) for that turn are left in pendingPrompts and state.runtimeRequests with status "pending" forever. The corresponding nodes and turn items also remain "waiting". This means an interrupted or failed turn leaves stale approval/user-input requests that never resolve, and respondToRuntimeRequest will still accept and send responses for them afterward.

In handleProjected for run.terminal, the code finalizes content and deletes state.activeTurn but never iterates pendingPrompts to cancel or resolve entries belonging to the terminal turn. Consider resolving all pending prompts for that turn (emitting terminal node/turn-item/runtime-request updates and sending extension_ui_response with cancelled: true to the transport) before clearing state.activeTurn.

🤖 Copy this AI Prompt to have your agent fix this:

In file @apps/server/src/orchestration-v2/Adapters/PiAdapterV2.ts around line 810:

When a Pi turn reaches terminal status, any pending runtime requests (extension UI prompts) for that turn are left in `pendingPrompts` and `state.runtimeRequests` with status `"pending"` forever. The corresponding nodes and turn items also remain `"waiting"`. This means an interrupted or failed turn leaves stale approval/user-input requests that never resolve, and `respondToRuntimeRequest` will still accept and send responses for them afterward.

In `handleProjected` for `run.terminal`, the code finalizes content and deletes `state.activeTurn` but never iterates `pendingPrompts` to cancel or resolve entries belonging to the terminal turn. Consider resolving all pending prompts for that turn (emitting terminal node/turn-item/runtime-request updates and sending `extension_ui_response` with `cancelled: true` to the transport) before clearing `state.activeTurn`.

[macroscopeapp]

🟠 High Adapters/PiRpcTransport.ts:209

When Stream.run(child.stdin) fails, only messages is failed — closed is never completed and outgoing is never ended. As a result, subsequent send calls still enqueue data and report success even though nothing is writing to the child, and request calls block until their full timeout instead of detecting the broken transport. The write-failure path should call markClosed (or at least complete closed and end outgoing) so callers see the transport is dead.

  yield* Stream.fromQueue(outgoing).pipe(
    Stream.run(child.stdin),
    Effect.mapError((cause) => new PiRpcTransportError({ operation: "write", cause })),
-    Effect.catch((error) => Queue.fail(messages, error)),
+    Effect.catch((error) =>
+      Effect.gen(function* () {
        yield* Queue.fail(messages, error);
        yield* markClosed();
      }),
    ),
    Effect.forkScoped,
  );

🤖 Copy this AI Prompt to have your agent fix this:

In file @apps/server/src/orchestration-v2/Adapters/PiRpcTransport.ts around lines 209-214:

When `Stream.run(child.stdin)` fails, only `messages` is failed — `closed` is never completed and `outgoing` is never ended. As a result, subsequent `send` calls still enqueue data and report success even though nothing is writing to the child, and `request` calls block until their full timeout instead of detecting the broken transport. The write-failure path should call `markClosed` (or at least complete `closed` and end `outgoing`) so callers see the transport is dead.

[macroscopeapp]

🟠 High Adapters/PiRpcProtocol.ts:103

The message_update schema requires a message field, but Pi's RPC protocol omits message from message_update events and sends only assistantMessageEvent. Every normal streaming update therefore fails decodeKnownEvent and is converted to PiRpcProtocolError, so text_delta and thinking_delta deltas are never projected. Making message optional (or removing it) aligns the schema with the actual protocol.

Suggested change

	Schema.Struct({
	type: Schema.Literal("message_update"),
	message: PiMessage,
	assistantMessageEvent: PiAssistantMessageEvent,
	}),
	Schema.Struct({
	type: Schema.Literal("message_update"),
	message: Schema.optional(PiMessage),
	assistantMessageEvent: PiAssistantMessageEvent,
	}),

🤖 Copy this AI Prompt to have your agent fix this:

In file @apps/server/src/orchestration-v2/Adapters/PiRpcProtocol.ts around lines 103-107:

The `message_update` schema requires a `message` field, but Pi's RPC protocol omits `message` from `message_update` events and sends only `assistantMessageEvent`. Every normal streaming update therefore fails `decodeKnownEvent` and is converted to `PiRpcProtocolError`, so `text_delta` and `thinking_delta` deltas are never projected. Making `message` optional (or removing it) aligns the schema with the actual protocol.

[macroscopeapp]

🟡 Medium Adapters/PiRpcProtocol.ts:467

projectPiExtensionUiRequest drops the validated timeout for editor requests, even though the user-input prompt type supports timeoutMs and the select and input branches preserve it. An editor request carrying a timeout is returned without its deadline, so the runtime can keep accepting input after Pi has already timed out the request. The editor branch is missing the conditional timeoutMs property that the other branches include.

🤖 Copy this AI Prompt to have your agent fix this:

In file @apps/server/src/orchestration-v2/Adapters/PiRpcProtocol.ts around line 467:

`projectPiExtensionUiRequest` drops the validated `timeout` for `editor` requests, even though the `user-input` prompt type supports `timeoutMs` and the `select` and `input` branches preserve it. An editor request carrying a timeout is returned without its deadline, so the runtime can keep accepting input after Pi has already timed out the request. The `editor` branch is missing the conditional `timeoutMs` property that the other branches include.

[macroscopeapp]

🟠 High Adapters/PiAdapterV2.ts:1006

startTurn emits active thread, running session, and running provider-turn updates and installs state.activeTurn before sending the prompt RPC. When requestData for the prompt rejects or times out, the function fails with ProviderAdapterTurnStartError, but the already-emitted active/running state and state.activeTurn are never rolled back and no terminal event is emitted — leaving the session and thread stuck running indefinitely. Move the state mutations and emissions to after the prompt RPC succeeds, or roll back state.activeTurn, reset the thread/session status, and emit a terminal event in the error path.

🤖 Copy this AI Prompt to have your agent fix this:

In file @apps/server/src/orchestration-v2/Adapters/PiAdapterV2.ts around line 1006:

`startTurn` emits `active` thread, `running` session, and `running` provider-turn updates and installs `state.activeTurn` *before* sending the `prompt` RPC. When `requestData` for the `prompt` rejects or times out, the function fails with `ProviderAdapterTurnStartError`, but the already-emitted `active`/`running` state and `state.activeTurn` are never rolled back and no terminal event is emitted — leaving the session and thread stuck running indefinitely. Move the state mutations and emissions to after the `prompt` RPC succeeds, or roll back `state.activeTurn`, reset the thread/session status, and emit a terminal event in the error path.

[macroscopeapp]

🟠 High Adapters/PiRpcProtocol.ts:346

projectPiEvent emits run.terminal on agent_end when willRetry is false, but agent_end only signals the end of one low-level run — compaction retries or queued continuations can still follow. Because consumers finalize and delete the active turn on run.terminal, any subsequent compaction or follow-up continuation output is silently dropped and the turn is reported complete prematurely. The terminal projection should be deferred to agent_settled (which means no continuation remains), while still carrying the final stop/error state from the last assistant message.

🤖 Copy this AI Prompt to have your agent fix this:

In file @apps/server/src/orchestration-v2/Adapters/PiRpcProtocol.ts around line 346:

`projectPiEvent` emits `run.terminal` on `agent_end` when `willRetry` is false, but `agent_end` only signals the end of one low-level run — compaction retries or queued continuations can still follow. Because consumers finalize and delete the active turn on `run.terminal`, any subsequent compaction or follow-up continuation output is silently dropped and the turn is reported complete prematurely. The terminal projection should be deferred to `agent_settled` (which means no continuation remains), while still carrying the final stop/error state from the last assistant message.

[macroscopeapp]

Effect service conventions review of the new Pi provider modules. Three mechanical convention issues found in PiAdapterV2.ts / PiAdapterV2.test.ts; the transport, protocol, driver, provider-snapshot, and text-generation modules otherwise follow the repo's Effect conventions (subpath namespace imports, Schema.TaggedErrorClass failures with structural attributes and preserved cause, dependencies acquired with yield* Service in PiAdapterV2Driver.create / PiDriver.create / makePiTextGeneration, no ManagedRuntime/runPromise outside test boundaries).

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

Inline import("...") type expressions bypass the module's import list. ../ProviderAdapter.ts and @t3tools/contracts are already imported at the top of this file, so it would be more consistent to add ProviderAdapterV2Error (here), ProviderAdapterV2EnsureThreadInput (line 846), ProviderAdapterV2RuntimePolicy, ThreadId, and ModelSelection (lines 928-930) to those existing type imports and reference them directly.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

IdAllocatorV2Shape is the legacy standalone shape type. Consider referring to the inferred service interface instead — readonly idAllocator: IdAllocatorV2["Service"]; (as GrokAdapterV2Options already does) — and dropping the then-unused type IdAllocatorV2Shape from the import on line 33.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

layer as idAllocatorLayer erases the service module namespace. Consider import * as IdAllocator from "../IdAllocator.ts"; and using IdAllocator.IdAllocatorV2 / IdAllocator.layer at the two use sites instead of the renamed layer export.

^{Posted via Macroscope — Effect Service Conventions}