CC Pocket: Control Codex and Claude from Your Phone Through a WebSocket Bridge
Mobile client for Codex and Claude — control coding agents from your phone via WebSocket bridge
At a glance
- What is it?
- CC Pocket is a Flutter mobile client for Codex and Claude that talks to a local Bridge Server over WebSocket, so your code and shell stay on your own machine. It is free, MIT licensed, and built for people who want to approve agent steps from a phone rather than a terminal.
- Who is it for?
- Adopt CC Pocket if you already run Codex or Claude on a machine you control and want to approve steps and review diffs from a phone without moving your code into a hosted IDE. Skip it if you need a single binary with no Node.js runtime, if you cannot expose port 8765 on your network, or if you depend on Claude subscription authentication without being willing to set BRIDGE_ALLOW_CLAUDE_OAUTH=1.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Dart, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What CC Pocket solves, and who it is actually for
Coding agents are long-running and interruptible. You start a task, wait, and then the agent stops to ask for approval. That rhythm is hostile to a terminal session you have to keep open. CC Pocket turns each agent session into a chat room on your phone: prompts, replies, approvals, and questions in one thread, with the same session resumable from the CLI or from a tablet or Mac.
The intended user is someone who already runs Codex or Claude on a machine they own. The README is explicit that the app is the interface and the Bridge Server runs locally on the machine with access to your projects, shell, git repository, and agent CLI, so code stays on your own hardware rather than moving into a hosted IDE. That is the whole pitch. If you are comfortable with a hosted agent platform, the local-first design is overhead rather than a feature.
The secondary audience is developers who want to fork. The README frames the MIT licence as permission to treat CC Pocket as a starting point, listing internal clients that combine Codex or Claude with Jira, Linear, GitHub, or private REST APIs, and reuse of the Bridge sync layer, approval flow, prompt history, git operations, file browsing, and image and diff viewers. That is an unusually direct invitation to strip the app down.
The Bridge Server architecture and where your code lives
The data flow is a three-hop chain, and the README draws it plainly:
CC Pocket app <-> Bridge Server on your machine <-> Codex / ClaudeThe app never talks to the agent directly. The Bridge Server is a Node.js process that runs on the host with your repositories, holds the session, and relays over WebSocket. The mobile app is Flutter, which is why the same codebase ships to iOS, iPadOS, Android, macOS, Linux, and Windows. The repository layout matches that split: apps/ for the Flutter client, packages/ for the bridge, functions/ for Firebase-backed pieces, and docs/ plus a large set of agent configuration directories at the top level.
Two consequences follow from this shape. First, the Bridge is a single point of failure: if the host sleeps or the process dies, new agent requests cannot be delivered. The README acknowledges this asymmetry in the weak-network section, stating that outgoing messages wait while you are offline and resend after reconnecting, missed streaming updates are recovered, but new agent requests need a connection. Second, the trust boundary is the WebSocket endpoint, not the app. Anyone who can reach port 8765 can drive an agent that has shell access to your projects. That is why the remote-access guidance leans on Tailscale rather than port forwarding.
Installing CC Pocket and starting a first session
The prerequisites are ordered and both matter. Install at least one agent CLI on the machine that will run your sessions (Codex or Claude), then install Node.js 20.18.1 or newer on that same machine. The Bridge will not start without a supported Node version, and it will start but have nothing to drive without an agent CLI.
Start the Bridge Server with the published package:
npx @ccpocket/bridge@latestThe Bridge prints a QR code. Install the CC Pocket app on your phone, scan that code, and the host is paired. Then pick a project, choose Codex or Claude, and start the session from the app. On the same network you can also connect by mDNS discovery or by typing a manual ws:// or wss:// URL instead of scanning.
For a host that should stay available, the Bridge can register itself as a background service. The README shows this exact command:
npx @ccpocket/bridge@1 setupService setup supports macOS launchd and Linux systemd, so Windows users have to manage the process themselves. Away from the local network, the recommended path is Tailscale on both the host and the phone, joined to the same tailnet, with the app connecting to ws://<host-tailscale-ip>:8765. Bridge flags and persisted service settings such as BRIDGE_ALLOWED_DIRS are documented in the Bridge package README rather than the top-level one, so plan to read packages/bridge/README.md before you tighten the configuration.
Claude authentication is the sharpest edge in the setup
Claude sessions use ANTHROPIC_API_KEY by default. If you want subscription authentication instead, the Bridge requires an explicit opt-in, and the README gives the reason in the same sentence: Anthropic's current official guidance has an unclear scope for this architecture. The variable is BRIDGE_ALLOW_CLAUDE_OAUTH=1, and the README points to docs/auth-troubleshooting.md for the failure cases.
Read that as a design constraint, not a bug. The project is telling you that it is relaying a subscription credential through a self-hosted bridge, and that the vendor's guidance does not clearly cover that pattern. If your organisation has a policy about where subscription credentials may be used, this is the line to check before you deploy anything. The README also notes that CC Pocket is not affiliated with, endorsed by, or associated with Anthropic or OpenAI, which is worth stating plainly to anyone who assumes a first-party integration.
The API-key path has no such caveat and is the default, so a team already using ANTHROPIC_API_KEY for other tooling will find the Bridge unremarkable to configure.
What you can do from the phone, and what the app will not do
The feature list is broader than a chat wrapper. Sessions support Markdown, voice input, and image attachments. The app browses files, inspects code and image diffs, stages changes, commits, pushes, and reverts, and it supports git worktrees so parallel tasks stay in separate directories. Codex Imagegen output can be generated and opened in chat, and video and audio files play in the app. On larger screens, chat, files, and Git changes appear side by side.
The limits are worth naming. Linux and Windows desktop builds exist but the README calls both experimental, and it gives the reason directly: the project does not have the same continuous verification coverage for those environments. That is a maintenance statement, not a marketing hedge, and it should shape where you install the desktop client. Screenshot capture on macOS requires Screen Recording permission for the terminal app running the Bridge, which is a common source of silent failure because the permission attaches to the terminal, not to CC Pocket.
There is also a hard boundary around connectivity. The weak-network handling covers your outgoing messages and streaming updates, but the README states that new agent requests need a connection. A phone that has been offline for an hour will not queue up a fresh prompt for later; it will simply fail to send it.
How CC Pocket compares with running the agent CLI over SSH
The obvious alternative is SSH plus tmux from a phone terminal client, and it is a real one: no Node.js process, no WebSocket endpoint, no app to install, and the agent runs exactly as it does on the desktop. The difference is the interaction model. SSH gives you a terminal, so approvals are keystrokes on a small screen and diffs are text you scroll. CC Pocket renders the session as chat with structured approval prompts, plus purpose-built viewers for code diffs and images and a Git panel with stage, commit, push, and revert actions.
That trade is the whole decision. SSH has a smaller attack surface and no extra runtime. CC Pocket has a larger one, because it adds a listening WebSocket service and a mobile app that must be paired, and it depends on Node.js 20.18.1 or newer being present on the host. In exchange you get a UI designed for the device you are actually holding when the agent asks its question.
A second alternative is simply staying at the desk. If your agent sessions are short enough that you are present for all of them, the Bridge adds a process to supervise and a port to reason about for no benefit. The README's own framing, that the app exists so you can start a task, approve the next step, and review the result away from the machine, tells you when it earns its keep.
Maintenance, release cadence, and what the MIT licence lets you do
The repository is not archived, and the last push was on 2026-09-14. Desktop releases for Windows, macOS, and Linux were all published on 2026-09-14 at version 1.131.0+248, so the three desktop channels move together. Mobile builds are distributed through the App Store and Google Play, with macOS also available as a .dmg from GitHub Releases and through Homebrew Cask with brew install --cask cc-pocket. Linux additionally has a community-maintained AUR package, cc-pocket-bin, which the project does not control.
Upgrade cost is concentrated in the Bridge, since the app updates through the normal store channels. The README pins the service setup command to @ccpocket/bridge@1, while the quick-start command uses @ccpocket/bridge@latest. If you register the Bridge as a launchd or systemd service, check which version that service is running before you assume it matches the app on your phone. The repository also carries a CHANGELOG.md, which is the place to look for behaviour changes between those desktop releases.
The licence is MIT, stated in both the README and package.json, and the README treats forking as an intended use. That is permissive in the ordinary sense: you can build a closed internal client on top. It does not grant anything regarding the agent CLIs themselves, which carry their own terms, and the project states it is not affiliated with Anthropic or OpenAI. Purchases are handled separately: Supporter purchases restore within the same Apple ID or Google account but do not sync across stores, so a supporter who switches platforms buys again. None of this is legal advice; read LICENSE and the vendor terms yourself.
Editorial conclusion
Adopt CC Pocket if you already run Codex or Claude on a machine you control and want to approve steps and review diffs from a phone without moving your code into a hosted IDE. Skip it if you need a single binary with no Node.js runtime, if you cannot expose port 8765 on your network, or if you depend on Claude subscription authentication without being willing to set BRIDGE_ALLOW_CLAUDE_OAUTH=1. Before committing, verify three things on your own host: that the Bridge starts and prints a QR code under your Node version, that your agent CLI is reachable from the same shell, and that the app reconnects after you drop the network mid-session.
Frequently asked questions
Does CC Pocket send my code to a cloud service?
No. The README states that the Bridge Server runs locally on the machine with your projects, shell, git repository, and agent CLI, and that your code stays on your own machine instead of moving into a hosted IDE. The app is the interface, and the session is relayed over WebSocket to that local Bridge.
How do I connect CC Pocket when I am away from my home network?
The README recommends Tailscale: install it on the host machine and the phone, join the same tailnet, then connect to ws://<host-tailscale-ip>:8765 from the app. On the same network you can instead use the QR code, mDNS discovery, or a manual ws:// or wss:// URL.
Why does CC Pocket need BRIDGE_ALLOW_CLAUDE_OAUTH=1 for Claude?
Claude sessions use ANTHROPIC_API_KEY by default. Subscription authentication requires explicit Bridge opt-in because, per the README, Anthropic's current official guidance has an unclear scope for this architecture. The project points to docs/auth-troubleshooting.md for details.
Can I run CC Pocket on Windows or Linux?
Yes, both desktop builds are published on GitHub Releases under windows/v* and linux/v* tags, and Linux also has a community AUR package. The README labels both experimental because the project does not have the same continuous verification coverage for those environments as it does for macOS.
What happens to my messages if my phone loses connection?
Outgoing messages wait while you are offline and resend after reconnecting, and missed streaming updates are recovered, according to the README. New agent requests are different: they need a connection, so a prompt composed while offline will not be delivered later.
Does CC Pocket work with both Codex and Claude in the same setup?
Yes. You install at least one agent CLI on the host, and when you pick a project in the app you choose Codex or Claude for that session. The Bridge relays to whichever CLI you selected.
Community notes