Pi
How LinkCode runs Pi, including its provider auth model, its upstream no-sandbox design, and why stopped threads can't be resumed.
Pi is bundled with LinkCode's host (the LinkCode daemon) and runs in-process — no separate binary, no subprocess, nothing to install.
Sign in
LinkCode has no sign-in flow of its own for Pi. Pi resolves credentials for roughly two dozen providers on its own, through its own auth file (~/.pi/agent/auth.json) or environment variables — whichever you've already set up for the provider you want to use, Pi picks up automatically.
You can also set an API key in Settings → Agents for the selected model's provider. LinkCode applies it as a runtime override for that thread only, taking precedence over Pi's own auth file and environment variables — it's never written to disk.
No sandbox, by design
Pi has no permission prompts and no sandbox. This is upstream Pi's own design, not a LinkCode gap. Pi's own security documentation states it runs "with the permissions of the user account that starts it," and that "real isolation needs to come from the operating system or a virtualization/container boundary." Every Pi thread in LinkCode executes tools fully autonomously. For untrusted repositories or unattended work, run it inside a container or VM rather than against a real checkout.
Model
There's no curated model list for Pi in LinkCode. Set one as free text in Settings → Agents, in provider/model-id form (for example anthropic/claude-sonnet-5). If you don't set one, Pi uses the first model available to it. There's no live model switch and no reasoning-effort control.
Thread history
A stopped Pi thread cannot be resumed. Once a thread has sent at least one prompt, trying to resume it fails — start a new thread if you need to continue the conversation.