Pane runs on your machine by default. Your code never leaves your machine because of Pane — it leaves only because the agents you choose to run (Claude Code, Codex, Aider, etc.) send context to their respective providers. Pane is a terminal host, not a proxy.

Local-first by default

Pane has no Pane-hosted backend and no cloud sync. Your repositories and worktrees live exactly where you put them on disk. Opening a pane does not upload your code anywhere.

Remote Pane is opt-in. When you connect to a VM, WSL box, or another machine, worktrees, terminals, and agents run on the remote host through your self-hosted Pane daemon. The desktop app connects with the pane-remote://... code printed by setup. Your code lives on that host; Pane still does not proxy AI API requests.

Open source — AGPL-3.0

Pane’s source is available at github.com/dcouple/Pane . You can audit the code, fork it, or build derivatives. AGPL-3.0 requires that network-served derivatives of Pane remain open source under the same license.

Telemetry disclosure

Pane uses PostHog  for anonymous product analytics. The data collected includes:

• Which features are used (pane creation, agent launch, keyboard shortcuts)
• Basic OS and app version
• Page views in the web app (runpane.com)

The following are never sent:

• File contents or code from your repositories
• Agent prompts or responses
• API keys or secrets of any kind
• File paths beyond worktree names

To opt out: Settings → Privacy → Disable analytics.

Agent permissions stay with the agent

Pane does not add or remove permissions on top of the agent. Each agent has its own permission model — Claude Code uses an allow-list at .claude/settings.json, Codex has its own approval prompts, Aider has confirmation flags, and so on — and that model behaves the same inside a Pane terminal as it does in any standalone terminal. Configure agent permissions in the agent itself.

Worktree isolation

Agents in one pane cannot read another pane’s worktree files through the OS unless you explicitly pass a cross-worktree path. Different working directories means different file-scope defaults for agents. This is a soft boundary enforced by working-directory conventions, not a kernel-level sandbox.

What Pane does NOT do

• Does NOT sandbox the agent process — the agent runs with your full shell permissions.
• Does NOT proxy AI API requests — requests go directly from the agent process to the provider’s API.
• Does NOT see agent prompts, completions, or the contents of files the agent reads or writes.
• Does NOT run a managed cloud execution service — Remote Pane connects to a daemon you install on your own machine.

Remote daemon security

Remote Pane authenticates every connection with a bearer token embedded in the pane-remote://... connection code. The token is generated on the host during setup and grants full session control to the holder.

Transport encryption: Tailscale wraps the connection in WireGuard encryption (ChaCha20-Poly1305). No ports are opened on the host. When Tailscale is unavailable, the SSH tunnel fallback provides AES-256 transport encryption with the daemon bound to loopback only.

Token rotation: Rotate tokens with pane --remote-setup on the host. Revoking a client in Settings > Remote Pane invalidates that client’s token immediately.

Device visibility: The host sees every connected client by device label. Disconnect or revoke any client from Settings > Remote Pane on the host machine.

Data isolation: Each data mode (Current Pane Data vs Isolated Daemon Data) uses separate databases and worktree directories. Sessions do not cross mode boundaries.

Reporting a vulnerability

Email hi@runpane.com with subject line [SECURITY]. We aim to acknowledge within 48 hours and reach a public disclosure decision within 14 days.