Coding agents are most useful when they can reach the real repository, shell, credentials, and toolchain. But remote access products often solve that by copying the repository into a cloud sandbox.
I wanted the opposite architecture: keep execution on machines I control, and make the remote layer a control plane rather than a second development environment.
That constraint led me to build PandaNpc, a client and local bridge for supervising Claude Code, Codex CLI, PandaCode, DeepSeek Harness, and Pi across Windows, macOS, and Linux.
This post explains the architectural choices that mattered, including the parts that were less obvious than “put a terminal in a browser.”
The host remains the source of truth
The simplest mental model is:
phone / web / desktop client
|
authenticated session relay
|
local host bridge
|
real coding-agent CLI process
|
repository + shell + local toolchain
The bridge does not upload a repository and recreate its environment elsewhere. The real CLI process runs on the host, in the real working directory, with the same Git configuration, compiler, package cache, MCP servers, and provider credentials it would use from a local terminal.
This is especially important once a setup stops being “one laptop plus one API key.” A Claude Code session might authenticate through a subscription, an API key, Amazon Bedrock, Vertex AI, or Microsoft Foundry. Another project may use Codex CLI. A third may point an OpenAI-compatible client at a private gateway or local model. Reimplementing every provider path in the remote service would make the service the new runtime. Talking to the existing CLI keeps the runtime local.
The relay carries session events, not a network tunnel
The host makes an outbound authenticated connection. It does not need a public IP or an inbound port. The relay moves application-level events: user messages, streamed assistant output, questions, permission requests, tool results, diffs, usage updates, and interrupts.
That distinction reduces the exposed surface. A remote client does not automatically receive arbitrary TCP access to the host. It receives the operations supported by the session protocol and allowed by the host configuration.
PandaNpc also has an encrypted private device mesh for cases where machines need stable private addresses and direct connectivity, but that is separate from the agent-session protocol. Keeping those two layers separate made both easier to reason about.
Reconnection is a data problem, not just a WebSocket problem
A live WebSocket is not enough for a useful remote coding session. Phones suspend apps. Browsers discard background tabs. Wi-Fi changes to cellular. A laptop sleeps and wakes.
The client therefore needs a reconnectable history and a monotonic view of session state. On reconnect, it must recover the messages and tool activity it missed without duplicating what it already rendered. Permission requests also need explicit identities and terminal states; otherwise an approval card can reappear as pending after the tool has already run.
This was one of the biggest implementation lessons: transport connectivity and session continuity are different problems. A green socket indicator does not prove that the UI has the complete conversation.
Multi-machine control needs stable identity
Once there is more than one host, “the current terminal” stops being a useful identifier. I ended up modeling the hierarchy explicitly:
- device: the Windows, macOS, or Linux host;
- project: a working directory on that device;
- engine: Claude Code, Codex, PandaCode, or another supported CLI;
- session: one reconnectable conversation inside that engine and project.
The same model lets a phone supervise a long task on a Linux server, approve a tool call on a Mac, and then inspect a diff produced on a Windows workstation without pretending those environments are interchangeable.
Remote approval must not widen host permissions
Remote convenience can quietly turn into remote code execution with unclear boundaries. My rule is that the client may answer a permission request, but it does not define what the host is allowed to request.
The host still owns the working directory, CLI permission mode, available tools, and operating-system privileges. Connection and session shares are revocable and time-limited. Browser automation is scoped to the active tab and retains approval boundaries. Mail tools are read-only, and attachment text is treated as untrusted input rather than instructions for the agent.
The remote interface should expose an existing authority boundary, not create a larger one.
Memory and scheduling belong above a single engine
Local CLI history is useful, but it is usually tied to one engine and one machine. I added an Agent Center layer for shared rules, skills, memories, and profiles, plus PandaNote for Markdown knowledge that agents can read and write through MCP.
Scheduled jobs use the same device/project/engine identity. A recurring task is assigned to a particular machine instead of an abstract cloud worker, which means it runs with the intended repository and toolchain.
The trade-offs are real
Keeping execution local is not universally better.
- The host must be online for the agent to work.
- Remote availability depends on the relay and the host connection.
- A remote UI does not sandbox a powerful local CLI.
- Provider limits and billing still belong to the CLI or provider account configured on the host.
- Cross-device history, approvals, and interrupts require more protocol work than a simple terminal stream.
For my workflow, those trade-offs are worth it because the repository never has to move and the remote session behaves like the CLI I already use.
Trying the architecture
The local host component is PandaPaw. On Linux or macOS:
curl -fsSL https://cos.pandanpc.com/pandapaw/install.sh | sh
On Windows PowerShell:
iwr -useb https://cos.pandanpc.com/pandapaw/install.ps1 | iex
Then the same hosts and sessions are available from the web, desktop clients, iPhone, or the Chrome side panel. The PandaPaw architecture and setup guide has the full flow and security boundaries.
I would be interested in feedback from people running several coding agents or several machines: where do you want the source of truth to live, and which remote actions would you refuse to expose at all?
Top comments (0)