Yep Anywhere: a browser front end for Claude Code and Codex

What the project is, and what it is not

Yep Anywhere is described as a complete browser interface for Claude Code and Codex, letting you start and supervise agents from another computer, a tablet, or a phone while they run on the machines you control.

That last clause is the whole architecture. The agents are not hosted. They are the CLI agents you already have, running on your own hardware, and this is the interface to them. The tag line in the readme is Mobile-first. End-to-end encrypted. Open source.

The readme makes the credential model explicit. You use an eligible Claude or ChatGPT plan through the account already signed in to the official provider tool, and Yep Anywhere can also show current subscription limits when the provider exposes them. So there is no separate account, no separate billing and no API key of your own, because the tool is driving the official client you have already authenticated.

The feature list is organised around what you can do once the interface is in front of you.

All your sessions, in one place. You can find and resume every Claude Code and Codex session, including those started from CLIs, VS Code, and first-party desktop apps, and disconnect or switch devices without interrupting active work. That last point is what makes it a remote control rather than a new front end, because the session lives where it always lived.

See the whole session. Follow the complete conversation, tool calls, and available thinking, or use a condensed view when you only need the result. The condensed view is the mobile-friendly half of the feature, because a transcript read on a phone is mostly scrolling past other people's tool calls.

Work comfortably from a phone. Approve tools, answer questions, upload files and photos, use voice input, and receive attention notifications. Approval from a phone is the capability that changes the workflow most, since a tool call that sits unapproved blocks the agent.

Keep many agents organized, with every project in one inbox, activity across sessions, steering of active work, queued follow-ups, searching older sessions, recaps, and the ability to fork or clone conversations.

Review and ship, with browsing of files, diffs and blame, line comments sent to an agent, checks on remotes, fast-forward pull, push, or sharing a session read-only.

Control test devices remotely, streaming Android devices and Apple Simulators with touch controls and adaptive quality.

And connect your way, using a direct connection or the end-to-end encrypted public relay, with no device pairing, VPN or port forwarding required for the relay path.

The project is TypeScript, MIT licensed, and the last push was on 2026-10-20 with recent desktop releases in the 0.3.x line.

Providers, and what is actually supported

The provider table is short and the notes column is what matters.

Claude Code is listed as the primary provider with full support, and the table records full diffs, approvals and streaming. Codex is also listed as full, with the note that it has full support including diffs and approvals.

So both primary providers get the same treatment, and the two capabilities called out separately, diffs and approvals, are the two that a reviewer would want before letting an agent touch a repository.

Then the readme lists the rest, and it is careful about the distinction. OpenCode, Grok Build, Gemini, and pi integrations are experimental. Claude Gateway is an advanced opt-in route, while Claude + Ollama remains available only for legacy compatibility. Capabilities vary.

That ordering communicates something specific. The two mainstream tools are the supported path, the four named integrations are being worked on, Claude Gateway is a deliberate choice for people with a specific setup, and Ollama is kept alive rather than developed. The word experimental here does real work, because it means the interface may not yet expose the same set of features for those providers.

The feature list also carries a provider-specific capability that would otherwise be hidden: Yep Anywhere can show current subscription limits when the provider exposes them. That is a small detail with a large practical value, because the usual failure mode of a subscription-based agent is not an error but a rate limit discovered at the worst moment.

The readme points at a provider guide for the details and notes that capabilities vary, which is the sensible caveat for a tool that presents a single interface over several underlying CLIs with different capabilities.

One more thing the description mentions is worth stating plainly, because it defines the trust model. No accounts are required, and the project uses your existing CLI session history rather than re-importing anything.

Installing it, and the one filesystem trap

The getting started section is short and the framing is the useful part: if you can install Claude Code or Codex, you can install this, and the runtime has a narrow dependency surface.

There are three routes. Desktop apps are in beta, with signed macOS and Windows installers on GitHub Releases, available now while release-readiness work continues. npm is the established path:

npm i -g yepanywhere
yepanywhere

And from source:

git clone https://github.com/kzahel/yepanywhere.git
cd yepanywhere
pnpm install
pnpm build
pnpm start

Then you open http://localhost:3400 in your browser, and the app auto-detects installed CLI agents. That last point is worth noting, because it means there is no configuration step where you list your agents. The tool finds what is installed.

The npm install is global and the source install is a pnpm workspace, and the package.json confirms the workspace structure with setup:core filtering the yep-anywhere package along with the server and client packages.

The filesystem warning is the most valuable thing in the section, and it is the kind of problem that would otherwise cost an afternoon. YA keeps a SQLite database in ~/.yep-anywhere, and SQLite takes a file lock per transaction. On a local disk that lock is free. On a network home directory, whether NFS, SMB or any mounted share, each one is a network round trip, slow enough to stall the server. YA checks at startup and leaves the database closed on a share rather than stall, which costs you issue associations and learned speech vocabulary until you move it.

The fix is to point the data directory at local disk:

YEP_DATA_DIR=/scratch/$USER/.yep-anywhere yepanywhere

That behaviour of refusing to open the database on a network share rather than hanging is a good design choice, because the alternative, a server that appears to start and then does not respond, is much harder to diagnose than one that starts with the database closed.

There is also a runtime version requirement worth noting: new server releases require Node.js ^22.16 || ^23.11 || >=24.10, and existing servers remain usable with the hosted client. The readme points at runtime upgrade guidance for the details.

Remote access, and the relay's honest limits

The remote access section is where the security model is set out, and it is unusually precise about the boundaries.

The easiest path is the free public relay, which gives passworded, end-to-end encrypted access from any browser, configured in Settings or from the command line for headless setups:

yepanywhere --setup-remote-access --username myserver --password "secretpass123"

Then you connect from anywhere at the remote path on the project site.

The important sentence is about what the relay can and cannot see. Remote Access application traffic is end-to-end encrypted, so the relay cannot read session contents. Public session shares are a separate opt-in path, and there the current relay operator can read shared content. No accounts are required.

So there are two different sharing models with two different trust properties, and the readme distinguishes them explicitly rather than lumping them together. The remote access path is encrypted end to end and the relay is just transport. A public share is readable by whoever operates the relay instance, which is why it is opt-in and separate.

Direct browser access has its own password under Settings, Local Access, or you can set it from the command line with yepanywhere --setup-auth for headless setup and recovery.

Then there are two alternatives for people who would rather not use the hosted relay at all. For a private network, the readme says a VPN such as Tailscale is usually simpler than deploying your own relay: put the phone and the development machine on the same private network and open the Yep Anywhere server from the phone. And for self-hosted public access, the advice is Caddy or any reverse proxy with SSL termination.

The reason the relay is worth the trouble at all is the list of things it avoids. With the relay path, there is no device pairing, no VPN and no port forwarding required.

Updates follow the same split. For the npm global install, npm update -g yepanywhere and then restart the server. For a source checkout, git fetch origin, git merge origin/main, pnpm install, pnpm build, and then restart with pnpm start.

The repository, and what the packaging implies

The top level of the repository shows a much larger project than the feature list suggests, and several entries are worth understanding rather than just noting.

There is a packages/ directory for the workspace, a site/ directory for the public site, a docker/ directory, a scripts/ directory, a docs/ directory and a topics/ directory. The .env.example documents the server's tunables in a way that says a lot about how the thing is built.

The logging block covers file logging, which is off by default, with separate levels for the general log and the file log, and a switch for pretty console output. The ports block notes the derivation, that the server is PORT, maintenance is PORT+1 and vite is PORT+2, with PORT defaulting to 3400.

Then there are the tuning knobs for the session index, and they read like someone who has debugged a multi-process problem. A periodic fallback rescan for the Codex session watcher, defaulting to 5000 milliseconds on macOS and 0 elsewhere, meaning disabled. A session index full validation interval of 30000 milliseconds, with 0 meaning validate on every request. A session index write lock timeout of 2000 milliseconds for multi-instance coordination. A session index lock stale threshold of 10000 milliseconds before stale locks are cleaned up. And a project scan cache TTL of 5000 milliseconds, with 0 meaning rescan on every request.

The write lock and stale lock settings together describe a system that expects more than one process to touch the same session index, which is consistent with a tool that reads session files written by other applications.

There is a YEP_PROFILE variable, giving a profile for the data directory, so a developer can run a separate instance without colliding with the main one.

The rest of the repository is documentation for people and for tools. There is an ARCHITECTURE.md, a PROGRAM.md, a GLOSSARY.md, a DEVELOPMENT.md, AGENTS.md, CLAUDE.md, GEMINI.md and AGENTS-RENDERING.md, plus a topics.md, which is a pattern for keeping a body of prose in version control. There is a SECURITY.md and a CODE_OF_CONDUCT equivalent in the LICENSE and NOTICE files, and a .yepignore file that presumably controls what the agent should not read.

The scripts section of package.json is where the maintenance discipline shows. Beyond the setup scripts there are check-and-sync pairs for references and for the Codex protocol, so scripts/update-codex-protocol.mjs has a --check mode used in CI to detect drift. There is an audit script for tool displays, several scripts for pruning and reporting on internationalisation placeholders, a script to find raw copy that has not been through the translation pipeline, an agent process monitor, an artifact capture script for the client, a Unicode maths training script, and Android interop fixtures with both check and write modes plus a native secure probe server.

The tooling choices are worth a mention too. Biome is the formatter and linter, there is an eslint.config.js as well, vitest is the test runner with vitest.config.ts, and both pnpm-lock.yaml and pixi.lock are present alongside pixi.toml, which suggests a Python component to the build.

Editorial conclusion

Adopt Yep Anywhere if you run coding agents on a machine you control and want to approve them, read their output and steer them from a phone or a second computer. Do not adopt it if you need to run the agents themselves in the browser, because the agents run on your machine and the project is the interface to them. Before you commit, set YEP_DATA_DIR to local disk, because the SQLite lock on a network home directory stalls the server, and read the runtime upgrade guidance, since new server releases require a recent Node.js and older servers remain usable only with the hosted client.

Frequently asked questions

Official sources

1. Issues
2. kzahel/yepanywhere on GitHub
3. License: MIT
4. README
5. Releases