Jep connects OpenCode, Codex and Anthropic’s Claude Code to a common remote-control system. Developers can reach their local coding agents through Telegram, a native Android app or another client connected to its gateway, according to the project’s GitHub repository.
The practical appeal is straightforward: a team using several coding agents should not need a separate phone-to-agent integration for every combination of client and harness. Jep puts a shared interface between those sides, with adapters handling the differences between agents.
That architecture is worth examining separately from the security of a deployment. A convenient remote interface can also provide access to an agent capable of editing files, running commands and using connected tools. Jep’s documentation describes several protective choices, but teams still need to establish what their particular setup allows.
How Jep Separates Clients From Coding Harnesses
Jep describes a hexagonal architecture centered on a HarnessAdapter interface. In plain terms, the core works against a common contract, while adapters handle agent-specific behavior. Clients sit on the other side of that core.
A coding harness is the software environment around the model: the CLI, session management, tools and permission behavior. Supporting a harness involves more than forwarding a prompt to a model API.
The repository identifies OpenCode as its flagship integration and describes full adapters for Claude Code and Codex. It also lists Pi among the supported harnesses, although the available README excerpt gives less detail about that integration. Those descriptions should not be read as a guarantee of identical capabilities across every harness. Source: Jep repository
The intended separation looks like this:
- Harness adapters translate agent-specific behavior into Jep’s shared interface.
- The core sits between harnesses and clients.
- Clients provide the user-facing controls, such as Telegram messages or an Android conversation screen.
- The gateway gives additional clients a token-authenticated HTTP interface with server-sent events, or SSE, for streamed updates.
SSE lets a server keep sending events over an open HTTP connection. Here, that supports a client receiving ongoing turn updates instead of repeatedly requesting the latest state.
The maintenance benefit follows from the structure. Three harnesses and two clients create six possible pairings. A shared contract aims to concentrate harness-specific work in three adapters and client-specific work in two integrations. That is an architectural illustration, not a measured reduction in Jep’s code or maintenance costs.
My view is that this separation is Jep’s strongest proposition. Adding a client should become less dependent on understanding every agent’s internals. The hard part remains inside the adapters: preserving permission requests, cancellation and session behavior accurately enough that the common interface stays trustworthy.
What Jep’s Clients Actually Offer
Jep’s repository lists several client surfaces, but they have different roles and distribution status.
| Client or interface | Documented capabilities | Practical qualification |
|---|---|---|
| Telegram bot | Streaming responses, expandable tool calls, permission prompts, stop controls, voice notes, Git and usage screens | A ready-made conversational interface |
| Android app | Conversations, streaming turns and notifications in a Jetpack Compose client | Connects to the gateway and requires pairing |
| macOS menu-bar app | Daemon status and a phone-pairing QR code | A companion utility, not a full conversation client |
| iOS app | SwiftUI app for iPhone and iPad | Requires building with Xcode; not listed on the App Store or TestFlight |
| Gateway | Token-authenticated HTTP and SSE | An integration surface for additional clients |
These capabilities and availability details come from the Jep README. Its examples of a web dashboard, Slack bot and desktop widget describe clients the gateway could enable, not evidence that all three ship as finished integrations.
The Telegram interface goes beyond sending a prompt and waiting for a final message. Jep says it displays thinking activity, tool calls and an answer draft that updates approximately every 700 milliseconds. Users can stop a turn or steer it with a replacement instruction. Voice notes are transcribed with Whisper, and the bot provides a receipt showing what it heard.
The repository also documents read-only Git status, log and diff screens, plus a push action requiring confirmation. Configuration controls expose MCP server and skill settings. MCP servers connect agents to additional tools or data, so those controls can affect what an agent can reach.
Usage screens report token counts, model and US-dollar costs as priced by the harness. I would treat those figures as workflow visibility, with final billing checked against the relevant provider. The documented source of the price is the harness, not an independent accounting system. Source: Jep repository
Setup Requirements and a Desktop Handoff Detail
Jep requires Node.js 26 or newer and at least one installed agent CLI: opencode, codex or claude. The daemon runs native TypeScript without a separate build step.
The documented npm installation and Telegram startup flow can be expressed as:
npm install -g @tinybig-ai/jep
export JEP_WORKSPACES="$HOME/your-project"
export JEP_TG_TOKEN="<your Telegram bot token>"
jep
This installs the daemon, selects a workspace and supplies the Telegram bot token before starting Jep. The path and token are placeholders to replace. These are documented setup commands, not commands executed for this article. Additional gateway clients require gateway configuration, including JEP_GW_PORT, and their own pairing or connection steps. Source: Jep repository
One consequential installation detail concerns Claude Code handoff. Jep says its macOS and Linux installers register a Claude Code hook so a desktop conversation can catch up after being continued from a phone. Before the next desktop message, the hook supplies what was said remotely.
If the transcript cannot be read, the documented behavior is to stop the message and tell the user to run claude -c. Setting JEP_NO_CLAUDE_HOOK=1 skips hook registration.
That is useful continuity behavior, but it also deserves an installation review. A remote-control tool can change desktop workflow through hooks as well as through its running daemon. Teams should account for both when documenting what gets installed.
Security Questions Before Enabling Remote Access
Jep’s README describes an isolated data home that leaves the CLI’s session store untouched, plus a daemon served over Tailscale or the local network. Those are relevant design choices. An isolated session store, however, is a storage boundary, not a filesystem sandbox. Source: Jep repository
The available evidence is documentation, not independent security or reliability testing. It also does not establish the completeness of controls described elsewhere in the repository. The questions below are deployment checks, not claims that Jep lacks those controls.
Who Can Reach the Gateway?
Teams should establish the actual bind address, reachable interfaces and firewall rules. A LAN service may be accessible to other devices on that network; a private-network deployment still needs appropriate device and user access controls.
The README’s HTTP-and-SSE description does not settle how traffic is protected along a particular deployment path. Verify transport protection before forwarding ports or placing a proxy in front of the gateway.
I would begin with access limited to known devices over a private network. The documented use case is personal or team remote control, and public reachability adds another set of systems and identities to defend.
What Authority Does a Token Grant?
Token authentication answers only part of the access-control problem. Teams should determine:
- How tokens are generated, stored, rotated and revoked.
- Whether access is scoped to particular users, workspaces or sessions.
- What happens when a paired phone is lost.
- Which Telegram accounts can issue commands or approve actions.
A bot token and a gateway token serve different integration roles. Both need deliberate handling, especially in logs, service definitions and configuration backups.
Frequently Asked Questions
3 questions
1Which Coding Agents Does Jep Support?
Jep lists OpenCode, Codex, Claude Code, Pi and additional harnesses. Its README specifically describes OpenCode as the flagship integration and full adapters for Claude Code and Codex.
