Skep: Enabling Local Coding Agents to Share Real-Time Sessions Across Devices

Anyone Running Agents on Multiple Machines Is Putting Up with the Same Problem

Many developers now run coding agents on multiple machines simultaneously: Claude Code on their laptop, another instance on a VPS, and occasionally Pi on their Mac. These agents all work fine on their own, but they're completely isolated from each other—context, plans, and intent are all locked inside their respective machines. Switch to another device, and you have to re-explain all the background from scratch.

According to the project's author, the solutions he tried either required uploading API keys to a third-party cloud, or were makeshift setups stitched together with SSH and tmux—high maintenance costs and insecure. So he built Skep: a lightweight session bus that lets coding agents on different machines join the same real-time session. The project is open source under the Apache-2.0 license.

The Core Problem Skep Solves

Multi-agent collaboration today has a structural contradiction: agents are inherently single-machine-bound. The context and plans you accumulate on machine A become useless on machine B. Most products solve this by centralizing state in the cloud, at the cost of keys, code, and session data all passing through third-party servers.

Skep takes the opposite approach—no centralized platform, just a session bus between machines. The author lists three specific pain points: context and intent can't flow across devices, existing solutions require centralized hosting, and the desire to keep using the local CLI you're already using.

Stack these three requirements together, and they actually rule out most of the "multi-agent collaboration platform" directions on the market.

How It Works

Skep's architecture can be summed up in one sentence: one machine acts as the master, other machines join using a short code and host, no account registration required, and no cloud relay.

There are three key design decisions:

The peer side runs your local CLI. Skep doesn't wrap Claude Code, Codex, or Pi, nor does it proxy prompts to a server. The agent remains the local program you trust; Skep only handles message passing at the session level.

Keys stay on their respective devices. The project explicitly promises not to collect or upload API keys, because there's simply no central server to receive them.

Designed for trusted network environments. Skep targets communication between machines you own, not open cross-organizational collaboration scenarios. This is evident from its security model—it assumes devices are mutually trusted.

Installation is straightforward: npm i -g @skepagent/skep, current version v0.1.15.

What Is a Session Bus

A session bus can be thought of as a specialized form of message queue or event bus in the context of agent collaboration. Traditional message middleware (like Redis Pub/Sub, NATS) handles passing messages between processes or services, while session buses like Skep pass session state—including current plans, context fragments, intent declarations, and other higher-level semantic information. The difference is that ordinary message buses only care about "who sent what," while a session bus also maintains "what state this session is currently in, which agents are participating, and how each party's context views are aligned."

Skep uses a master-peer topology rather than decentralized P2P because multi-agent collaboration requires an authoritative node to determine the session's initial state and participant list. The short-code mechanism reduces the coordination cost of joining a session: the master generates a short code, and peers enter the short code to locate the corresponding session, similar to a room number in an online meeting. This design avoids the complexity of account systems and identity verification, but also means its security boundary depends entirely on the trustworthiness of the underlying network.

Trade-offs vs. Cloud Platform Solutions

Skep's choice represents a clear engineering stance: the trust boundary should be drawn at the devices you control, not outsourced to a third party.

Cloud platform solutions offer the advantage of being ready out of the box—hosted session state, unified collaboration experience, well-integrated billing. But the cost is a larger trust surface: your keys, code snippets, and session context all flow through someone else's servers.

Skep's approach is more "bare-bones": a session is just a bus between machines, no extra magic. This means a smaller exposure surface, but also means you need to manage network connectivity between machines yourself, and it's not suitable for scenarios spanning trust domains.

In the author's own words: this is for "trusted devices on your own network."

Trust Boundaries and Threat Model

In security engineering, a trust boundary is the dividing line between areas of different trust levels in a system. Cloud platform solutions draw the trust boundary at the edge of the third-party provider's servers, meaning you must trust that the provider won't abuse, leak, or be compromised. Skep shrinks the trust boundary to within your own device network, assuming the network channel between devices is itself secure (e.g., LAN, WireGuard tunnel, or SSH encrypted channel).

But this doesn't mean Skep has no threat model. Potential risks it faces include: short codes being guessed by other devices on the LAN, the master node being compromised and affecting the entire session, and plaintext messages being sniffed on untrusted networks. Therefore, Skep is suitable for deployment in environments where you've already established encrypted channels via VPN or private networks. If your devices are spread across the open internet, using Skep directly without network-layer encryption may not be less risky than handing data to a cloud platform—only the risk type shifts from "trusting the provider" to "trusting your own network configuration."

Who Should Use It

If you meet the following conditions, Skep is worth trying:

• You run coding agents on two or more devices and want them to share intent and context
• You're concerned about handing API keys to a third-party cloud platform
• You're already using the local CLI (Claude Code / Codex / Pi) and don't want to switch toolchains
• Your devices are already on the same trusted network

Conversely, if you need cross-organizational collaboration, or don't want to worry about machine-to-machine connectivity yourself, centralized solutions are still more convenient in terms of experience.

The project is at skepagent.com, and the repository is on GitHub (Guxiaodong941005/skepAgent). The author welcomes discussion in the comments about protocol design and threat model related questions.

One-line Summary

Skep is an open-source session bus that lets local coding agents on multiple machines share sessions, with keys never going to the cloud.

Paragraph Summary

Skep is an open-source project under the Apache-2.0 license, designed to solve the problem of coding agents on multiple machines being isolated from each other. It uses a master-peer architecture where one machine acts as master and others join the same real-time session via a short code, with no account registration or cloud relay required. Agents still run the local CLI on each device (like Claude Code, Codex, Pi), and Skep only handles session-level message passing—it doesn't wrap or proxy prompts to a server. API keys stay on their respective devices because there's no central server to receive them, thus reducing the trust surface. Compared to cloud platform solutions, Skep sacrifices out-of-the-box convenience in exchange for a smaller trust boundary, positioned as communication between owned devices within a trusted network, not suitable for cross-organizational or cross-trust-domain collaboration.