| 1 | # Pi |
| 2 | |
| 3 | T3 Code can use your existing Pi coding agent installation while keeping Pi's models, auth, |
| 4 | extensions, skills, context files, and native session history. |
| 5 | |
| 6 | ## Set Up Pi |
| 7 | |
| 8 | 1. Install [Pi](https://pi.dev) on the machine running the T3 Code server. Pi requires Node.js |
| 9 | 22.19 or newer; its platform installers can install Node if needed. T3 Code supports Pi |
| 10 | 0.80.5 or newer. |
| 11 | 2. Run `pi` in a terminal, then `/login` to connect your model provider or configure its API key. |
| 12 | 3. Open T3 Code Settings, enable Pi, and refresh the provider. |
| 13 | |
| 14 | For an npm installation, use: |
| 15 | |
| 16 | ```sh |
| 17 | npm install -g --ignore-scripts @earendil-works/pi-coding-agent |
| 18 | ``` |
| 19 | |
| 20 | If `pi` is not on the server's `PATH`, set Pi's binary path to the executable. Provider environment |
| 21 | variables and launch arguments are also available for installations that need a custom agent |
| 22 | directory, endpoint, or model configuration. `--provider` must be paired with `--model`. T3 Code |
| 23 | rejects launch arguments that change Pi's execution mode or select a session because T3 owns those |
| 24 | parts of the process lifecycle. |
| 25 | |
| 26 | On a remote or headless server, connect to that machine over SSH and run `pi`, then `/login`. |
| 27 | Open the authorization URL on your own computer. If the callback cannot reach the server, |
| 28 | paste the final redirect URL or authorization code back into Pi when prompted. You can also |
| 29 | set your model provider's API-key environment variable in the Pi instance's settings; mark |
| 30 | secret values as sensitive. |
| 31 | |
| 32 | Update installer-managed Pi with `pi update`. If another package manager owns the installation, |
| 33 | update it through that manager instead. For example, a Nix profile installation uses |
| 34 | `nix profile upgrade pi`. |
| 35 | |
| 36 | ## What Carries Over |
| 37 | |
| 38 | T3 Code discovers the models reported by Pi and exposes their supported thinking levels. The |
| 39 | thinking picker marks the discovered active model's configured level as its default without |
| 40 | overriding it. Other models keep their Pi defaults when no level is selected. Threads |
| 41 | use Pi's native session files for resume, rollback, and forks within the same Pi instance. Forks |
| 42 | preserve the native conversation through the selected turn in the destination workspace. |
| 43 | Switching providers uses portable conversation context. Extension |
| 44 | dialogs appear in the T3 Code composer, and the composer context meter follows Pi's own usage |
| 45 | reporting while a response streams and after it settles. |
| 46 | |
| 47 | Pi skills appear in the composer's `$` menu. This includes user skills and project skills that Pi |
| 48 | loads for the current workspace; selecting one uses Pi's native skill expansion. |
| 49 | |
| 50 | Pi loads its normal user and project extensions. Blocking `select`, `confirm`, `input`, and `editor` |
| 51 | dialogs work in T3 Code. Notifications appear in the work log. Pi terminal decoration such as |
| 52 | titles, status lines, and widgets does not have a T3 Code equivalent. |
| 53 | |
| 54 | ## Permission Modes |
| 55 | |
| 56 | T3 Code applies the composer permission mode through Pi's blocking tool hook: |
| 57 | |
| 58 | - **Supervised** asks before commands, file changes, and extension tools. Read-only tools continue. |
| 59 | - **Auto-accept edits** allows Pi's edit and write tools, but asks before commands and extension |
| 60 | tools. |
| 61 | - **Full access** allows tools without T3 Code approval prompts. |
| 62 | |
| 63 | The **Auto** option is not shown for Pi because Pi does not expose an AI approval reviewer. |
| 64 | Threads that already stored Auto before Pi support was added behave and display as Supervised. |
| 65 | |
| 66 | Changing the mode restarts the Pi provider session and resumes the same native conversation. The |
| 67 | policy covers Pi tool calls; it is not an operating-system sandbox, and code that a trusted Pi |
| 68 | extension runs outside a tool call remains governed by Pi's own extension trust model. |
| 69 | |
| 70 | T3 Code's `delegate_task` tool creates durable child threads in the shared subagent UI. If the user |
| 71 | installs Pi's example `subagent` extension, T3 Code also shows its task progress and results in that |
| 72 | UI. Pi runs those children without a session, so they cannot be opened or resumed as T3 Code |
| 73 | threads. |
| 74 | |
| 75 | ## Troubleshooting |
| 76 | |
| 77 | - If Pi is unavailable, confirm that the configured binary runs on the server machine, then refresh |
| 78 | the provider in Settings. |
| 79 | - If no models appear, open Pi directly and confirm its authentication and model configuration. |
| 80 | - If discovery cannot complete, T3 Code keeps Pi available with the `Pi default` model. Start a |
| 81 | thread to let the interactive Pi session handle any startup prompt. |
| 82 | - If a project extension is missing, approve the project in Pi, then start a fresh provider session. |
| 83 | - If a project skill is missing from the `$` menu, approve the project in Pi and refresh the provider. |
| 84 | - The context meter appears once Pi reports usage for the thread. Some model providers only |
| 85 | report usage when a response completes, so the meter can wait for the first reply. |