feat(providers): add Pi coding agent

[StiensWout]

Problem

Pi users depend on their existing models, auth, extensions, skills, context files, and native session history. T3 Code did not have a Pi provider, and a shallow CLI wrapper would lose the customization and session behavior that make Pi useful.

Solution

This adds Pi as an Early Access provider on Orchestrator V2:

• T3 speaks Pi's stdio JSONL RPC protocol through the user's own installation and discovers models, thinking levels, commands, skills, and auth from Pi itself.
• User and trusted project skills appear in the shared $ menu; selecting one uses Pi's native skill expansion while unrelated dollar-prefixed text remains unchanged.
• The thinking picker asks Pi for its effective configured level, badges that real choice as Default, and keeps inheritance internally so T3 does not override Pi.
• T3 threads use Pi's native session files for resume, current-branch fork, rollback, steering, and session naming.
• Extension dialogs, notifications, status rows, MCP tools, and resumable subagents project into the existing T3 lifecycle surfaces.
• The launcher replaces only the conflicting official Pi subagent extension, deduplicates explicit extension arguments, and restores user/npm extensions plus project extensions accepted by Pi's saved trust decision.
• Pi's session statistics feed the shared composer context meter. The ring tracks the active thread's context window while the popover exposes cumulative tokens processed across that Pi session.
• Turn settlement, retry and compaction recovery, child cancellation, process teardown, and fork rollback paths fail closed without leaking or corrupting the active native session.
• User Stop cleanly retires the Pi runtime after preserving the interrupted terminal, without surfacing the expected process closure as a provider error.

The MCP bridge, resumable subagent work, and per-model thinking support originated in @mwolson's stacked contribution and retain that authorship.

Related work

Closes #397.
Closes #402.
Addresses #6685.

This supersedes the Pi implementations in #2211, #2748, #2800, #2812, #2831, #2856, #3818, #3947, #4355, #4445, #5688, #5882, and #6319.

This incorporates StiensWout#34 by @mwolson.

Validation

• 40 focused Pi tests, reduced from 48 by removing duplicate helper and branch matrices while strengthening observable lifecycle coverage.
• Targeted contracts and web typechecks pass. The full server typecheck reaches one inherited feat(orchestrator): introduce new orchestrator #2829 settings-layer error in ProviderSessionManager.test.ts; this pass introduces no additional server type errors.
• Targeted changed-file lint and formatting.
• Both generated Pi extensions parsed independently as TypeScript.
• Live validation against Pi 0.84.2, including provider discovery, multi-turn context usage, MCP, extension UI, native subagents, steering, rollback, and provider handoff.
• Mobile parity audited for the shared Codex and Claude surfaces; Pi-specific mobile behavior is intentionally limited to provider identity and model selection.

Proof

Provider discovery

End-to-end Pi turn

Context meter persists across turns

The active context stays at 21k/272k while Pi's cumulative session total rises from 90k to 111k after the next completed turn.

Configured thinking default

Pi's effective setting appears as the labeled default while the internal selection continues to inherit from Pi.

Native resumable subagent

Native steering

Checkpoint and Pi session-tree rollback

Clean Stop

Stopping an active Pi turn leaves the expected interrupted terminal and no provider stream error.

Stacked on #2829 (t3code/codex-turn-mapping) until that branch lands.

Built by GPT-5.6 Sol in T3 Code through Codex.

---

Note

High Risk
New subprocess RPC provider with extension injection, MCP credentials in env, and complex turn/session state; bugs could corrupt threads, leak tokens, or wedge Pi processes.

Overview
Pi is wired in as a first-class orchestration-v2 provider: the server spawns the user’s pi binary in RPC mode and speaks JSONL over stdio (PiRpc), with a large PiAdapterV2 that maps Pi events into T3 turns (streaming, tools, compaction, retries, extension UI → runtime requests, subagent child threads, fork/rollback/steer, context usage).

Launch wiring materializes T3-owned Pi extensions (MCP bridge + subagent override), injects bearer/MCP env when a session exists, and deduplicates/filters user and trusted project extensions so Pi customization is preserved without conflicting official subagent registration.

Mobile gets a Pi provider icon and “Pi” display label in model options; ~1.5k lines of PiAdapterV2 tests cover the RPC contract and lifecycle edge cases.

^{Reviewed by Cursor Bugbot for commit d7a2028. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Add Pi coding agent as a provider with orchestration-v2 integration and text generation

• Registers Pi as a built-in provider driver with settings schema, status checks, model discovery via ephemeral RPC, and an Early Access badge in the settings UI.
• Introduces a Pi RPC transport layer (PiRpc.ts) and orchestration-v2 adapter (PiAdapterV2.ts) that communicate with pi --mode rpc over stdio JSONL.
• Injects T3-owned extensions into Pi sessions: a subagent override that persists child session files and an MCP bridge that registers T3 tools and injects orchestration guidance into the system prompt.
• Adds Pi-backed text generation (PiTextGeneration.ts) for commit messages, PR content, branch names, and thread titles using ephemeral pi --mode rpc sessions with 180s timeouts and structured JSON decoding.
• Surfaces live provider thread contextUsage in deriveLatestContextWindowSnapshot, preferring it over compaction-derived estimates when present.
• Risk: formatProviderDisplayName is removed from contextWindow.ts; any callers importing it from that module will break.

^{Macroscope summarized d7a2028.}

[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: 74f9bc83-7075-4d59-af07-9abe9487a07d

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]

Effect service conventions review of the new Pi provider code. Two error-modeling issues found; everything else (namespace subpath imports, Effect.catchTags usage, layer/driver construction acquiring ChildProcessSpawner/FileSystem/IdAllocatorV2/ServerConfig from the environment, Schema.TaggedErrorClass failures) follows the conventions.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

One consistency finding on the new web provider icon wiring. Everything else in the web scope (providerDriverMeta.ts, ProviderModelsSection.tsx, contextWindow.ts, session-logic.ts, AddProviderInstanceDialog.tsx) is registry/data-only and matches the existing per-driver patterns.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

Approvability

Verdict: Skipped

Macroscope did not run approvability analysis for this PR. Diff is too large for automated approval analysis, so this PR cannot be approved automatically.

^{You can add or adjust custom eligibility rules. Learn more.}

[macroscopeapp]

One finding on the Pi icon geometry after the tile removal. Everything else in the web scope (provider icon map, driver meta, model placeholder, display-name and picker option entries) follows the existing per-provider patterns.

^{Posted via Macroscope — UI Consistency}

[macroscopeapp]

Effect service conventions: one finding — a raw child-process stderr payload is copied into a log annotation. Elsewhere in this repo process output is reported as lengths only (stdoutLength/stderrLength, lineLength), with explicit tests asserting stderr is not retained in diagnostics.

^{Posted via Macroscope — Effect Service Conventions}

[macroscopeapp]

Two log annotations in the new Pi adapter copy Pi's raw wire error text into the observability stream. Everything else in the Pi files (error attributes, cause handling, driver/layer shape, dependency acquisition) matches the repo's adapter conventions.

^{Posted via Macroscope — Effect Service Conventions}

[astarktc]

Live-tested this branch today on macOS against a heavily customized Pi 0.84.2 install (7 extension packages, RPC mode) — overall it held up impressively: provider/model discovery, native session resume, checkpoint revert with correct post-rollback session reconciliation, steer/queue, the MCP bridge, and cross-provider delegate_task all worked. One real bug found:

Pi extension re-discovery misses settings.json package extensions

discoverPiUserExtensions (piT3McpInjection.ts) re-adds only file-based extensions found in ~/.pi/agent/extensions/ (plus trusted project .pi/extensions). Extensions installed as packages in ~/.pi/agent/settings.json — npm specs whose entry points are declared via the pi.extensions field of their own package.json under ~/.pi/agent/npm/node_modules/<pkg>/ — are silently dropped when the launcher spawns Pi with discovery disabled.

Impact in my setup: all seven packages vanish (pi-lens, pi-subagents, pi-intercom, pi-mcp-adapter, pi-web-access, pi-messenger, @gotgenes/pi-anthropic-auth). The last one is the loud failure: it shapes requests for Anthropic subscription auth, so without it every turn dies with Anthropic's third-party-app 400 ("Third-party apps now draw from your extra usage…") — which presents as a Pi/provider failure rather than a dropped extension.

Workaround that worked: adding --extension /Users/<me>/.pi/agent/npm/node_modules/@gotgenes/pi-anthropic-auth/src/index.ts to the Pi provider's launch arguments (nice that user launchArgs survive the spawn).

Fix sketch: for each settings.json packages entry, resolve the installed dir under ~/.pi/agent/npm/node_modules/, read its package.json pi.extensions array, and re-add those paths alongside the discovered file extensions (still excluding/overriding the official subagent, as you already do).

[StiensWout]

[gpt-5.6-sol] RESPONDING ON BEHALF OF WOUT:

Confirmed, this was a real gap. Fixed in f015a6c2a, with Pi package-filter parity completed in bdfd4eca2, after validating Pi 0.84.2 package-manager conventions and the current published pi-subagents layout.

T3 now reads user npm package specs from ~/.pi/agent/settings.json, resolves scoped/versioned installs under the Pi agent npm root, and restores existing pi.extensions entrypoints. Pi’s object-form include/exclude and autoload: false filters are preserved, empty lists remain disabled, malformed/missing manifests are ignored, and pi-subagents remains intentionally replaced by T3’s resumable subagent override rather than being registered twice.

The existing discovery test covers a normal npm extension, the reported scoped Anthropic auth shape, filtered and disabled packages, and the real pi-subagents ./index.ts convention. All 40 focused Pi tests pass.

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 2 potential issues.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit f015a6c. Configure here.}

[astarktc]

Follow-up to the extension re-discovery fix (f015a6c): project-local .pi/extensions are still dropped for projects the user has trusted via pi's own prompt.

Symptom: a Pi thread spawned by T3 gets none of its project-local extensions (<project>/.pi/extensions/), even though a plain pi run in the same cwd loads them without any trust prompt. In my case that silently drops the extensions that inject session-start context, so T3-spawned threads orient blind.

Root cause: discoverPiUserExtensions (apps/server/src/orchestration-v2/Adapters/piT3McpInjection.ts) only adds the project root when settings.json has defaultProjectTrust: "always". But pi's primary trust model is per-project: decisions are recorded in ~/.pi/agent/trust.json and resolved with nearest-ancestor lookup (core/trust-manager.ts findNearestTrustEntry), checked before defaultProjectTrust in core/project-trust.ts. Most users never set defaultProjectTrust — they answer pi's trust prompt once, which writes trust.json. The re-discovery ignores that file entirely, so a recorded "Trust"/"Trust parent folder" decision — exactly the standing trust the code comment demands before bypassing pi's prompt with explicit --extension paths — has no effect.

Suggested fix: consult trust.json with pi's nearest-ancestor semantics before falling back to defaultProjectTrust; an explicit per-project false should win over defaultProjectTrust: "always" (matching pi's own precedence). Two details worth keeping: pi canonicalizes trust keys (canonicalizePath), so retry the lookup with the realpath'd cwd; and skip non-boolean values in the walk like unset entries.

I have this working locally — patch + tests here if useful: astarktc@9c3c80d97 (the new tests cover trusted-ancestor lookup and explicit-false-overrides-always).

[StiensWout]

[gpt-5.6-sol] RESPONDING ON BEHALF OF WOUT:

Confirmed, this is a real issue and is fixed on the PR head at d7a2028. I validated the behavior against Pi 0.84.2 and your patch: T3 now reads the canonical Pi trust store, follows the nearest-ancestor decision, lets an explicit false override the always default, and falls back to the default only when no saved decision exists. Malformed trust data fails closed. I folded the coverage into the existing project-extension trust test to keep the suite focused. Thanks for the precise report and patch.

[astarktc]

Bug: Pi extension re-discovery passes macOS AppleDouble sidecars as --extension, aborting every Pi spawn

Third extension-discovery issue in the same area as my two earlier reports (settings.json package extensions; trust.json).

discoverPiUserExtensions includes any directory entry ending in .ts/.js — including macOS AppleDouble metadata files (._name.ts, left behind when files are copied through a non-xattr-aware channel like scp/sshfs). Since pi treats a parse failure on an explicit --extension path as fatal (observed on pi 0.84.2: Error: Failed to load extension ... ParseError → exit, Hint: Start without extensions using "pi -ne"), a single stale ._*.ts in ~/.pi/agent/extensions/ kills every Pi turn with PiRpcError: Pi RPC read failed: pi process closed stdout — while interactive pi keeps working, because pi's own discovery skips dotfiles.

Repro:

1. printf 'junk' > ~/.pi/agent/extensions/._anything.ts
2. Start any Pi thread → turn fails with the stdout-closed RPC error.

Suggested fix: skip dotfile entries (entry.startsWith(".")) in discoverPiUserExtensions, matching pi's own loader behavior. Diagnosis note: pi's stderr (which names the offending file) is only logged at debug level as a length — surfacing it in the spawn-failure error would have made this a one-look diagnosis.