Agents Anywhere Puts Claude Code, Codex, and DSH on Your Phone: A Mac mini Test
How do you manage Codex, Claude Code, and DSH from a phone? I tried Agents Anywhere
Using Claude Code to write code involves an awkward kind of waiting. You ask it to analyze a project, track down a bug, or run a round of tests. It works away in the terminal for a while, then stops and asks: "Should I execute?" If you happen to have stepped away from your desk, the task has to wait until you come back. The AI has already started working, but a human still has to stand watch, which feels a bit like being a cyber supervisor.
Recently, I tried an open-source project on a Mac mini: Agents Anywhere. The computer keeps running Claude Code as usual, and I can use my phone to open the same session, look at results, reply to questions, and keep operating when needed. It also supports OpenAI Codex, Claude Code, and DeepSeek Harness (DSH). If you switch back and forth between several coding agents, this is more worth attention than a simple "phone remote control for Claude." This time I actually tested Claude Code on the Mac mini; Codex and DSH are officially listed as supported.
Figure 1: Screenshot of the homepage. The agent on the computer continues to use its original working environment, with phones and browsers providing access points. Source: Agents Anywhere official site.
First, understand: what exactly is the phone operating?
Agents Anywhere is a workbench for managing AI coding tools. Claude Code, Codex, or DSH is responsible for executing tasks; Agents Anywhere helps you connect devices, manage sessions, and puts the operation entrance on computers, phones, and tablets.
The project is on the Mac mini, the dependencies are on the Mac mini, and Claude Code also runs on the Mac mini. After switching to the phone, all of this stays where it was. You don't need to stuff another development environment into your phone.
Some common terms:
| Term in the docs | What it means |
|---|---|
| Work device | The computer or server that actually does the work; the project and execution environment live here. |
| Agent / Runtime | Claude Code, Codex, DSH, and the components that run or connect them. |
| Connector | The connection service on the work device that wires agents, files, and the terminal into the workbench; the desktop client has it built in. |
| Session | The conversation and execution record for one task; opening it across devices opens the same session. |
Supported work devices include Mac and Windows computers, and Linux development machines or headless servers can be connected through a standalone Connector. The precondition is that the work device stays powered on and online, and that the Connector and corresponding Runtime are running normally. Turn off the computer, and the AI on your phone can't keep working.
My test: having Claude Code check the disk, then viewing the results from my phone
I gave Claude Code on the Mac mini a very down-to-earth task: analyze disk space and find files that can be cleaned up.
In development, the project itself may not be that large, but build caches set up camp on the hard drive first.
This analysis listed Flutter build caches, iOS DeviceSupport, Rust / Tauri build artifacts, plus Playwright browsers, JetBrains, Homebrew, Codex Runtime, and model caches, among other things.
The result it gave: about 27GB of potential cleanup space, with a recommendation to prioritize about 17.6GB. For the freshly compiled Rust / Tauri build directories, it suggested keeping them for now, to avoid waiting through another compile after deleting them.
Figure 2: Composite screenshot from my Mac mini test. Bottom left is the original terminal, middle is the desktop workbench, right is the phone. The screen is at the stage where the analysis is done and it is asking "Should I execute?"; 27GB is cleanup candidates, 17.6GB is the recommended priority, not space that has already been freed.
The sequence for this operation was simple: first run the task on the computer, open the corresponding session through Agents Anywhere; then, on the phone, select the already-connected Mac mini and enter the same Claude Code session.
The analysis results from the computer were still on the phone, including tables, paths, and suggestions. After seeing "Should I execute?", you can reply directly, ask it to continue, or adjust the cleanup scope. If you need to troubleshoot yourself, you can also open a remote terminal.
What this saves is the hassle of re-explaining context. Otherwise you might have to send logs to your phone first, then open another chat window and explain: "On that computer just now, that project, that directory..." After explaining all that, the enthusiasm for going out is almost gone.
However, you still need to review the cleanup suggestions yourself. Caches that can be regenerated may still need to be re-downloaded or recompiled after deletion; "cleanable" and "deleting it has absolutely no cost" are two different things. I would first ask it to list paths, sizes, and impact, and only after confirming would I act, rather than handing the whole hard drive over to a "you decide."
Why I care that it supports Codex, Claude Code, and DSH
When you only use one tool, remote access mainly solves the "what if I leave the computer" problem. Once you start using two or three tools, another question appears: where exactly is the task?
The same project may have several terminals open, and different machines may be running different tasks. When you come back after a while, you first have to figure out which window belongs to whom, and which task is waiting for a reply. The more tools there are, the more time these small switches eat up.
Agents Anywhere puts the integration of Codex, Claude Code, and DSH, plus device, project, and session management, into the same workbench. You can find the device and project first, then enter the corresponding session to check progress.
Figure 3: The official site's display of support for three agents, Codex, Claude Code, and DeepSeek Harness, plus device, project, and session management. The projects and tasks shown are official demos. Source: Official product page.
This is attractive for people who like choosing a tool based on the task. Use Claude Code today, switch to Codex tomorrow, or bring in DSH; at least there is a unified entrance for remotely checking and managing tasks, without having to find a new phone-access solution every time you switch agents.
The unified workbench manages these tools and sessions. It does not mean Claude's context automatically becomes Codex's context, nor can you infer from this that several agents will automatically divide up work and collaborate. Every time you open a session, you still need to confirm which device, which project, and which Runtime you are connected to.
Different Runtimes may differ in capabilities such as model selection, approval, interruption, and resume. The official site also reminds you that the capabilities shown in the client prevail. Having a name on the support list is not the same as every button behaving identically.
For me, the value of multi-Runtime support is maintaining fewer operation entrances. As for which agent is better for a given task, that still depends on the task itself; the workbench won't make that choice for you.
Beyond remote messaging, what are files and terminal for?
In development, an agent saying "done" is usually not enough to put your mind at ease.
You might want to see what the files look like after changes, inspect the code diff, or run a command yourself to confirm the result. Agents Anywhere provides workspace file browsing and preview, attachment upload and download, and a remote shell and interactive terminal.
For example, if the agent says a test failed, you can open the terminal and check the logs; if it says a config is fixed, you can look at the file; if you need to confirm the current branch, you can check Git status. These operations all happen on the work device where the task lives.
Figure 4: Official "Files and Terminal" feature page. It shows the accessible workspace capabilities; actual operations still depend on the current Runtime and client. Source: Official product page.
I prefer using the phone for short operations: looking at a result, answering a question, checking a file, or adding one command. For continuous coding or comparing large diffs, going back to the computer is usually more comfortable. The phone screen is only so big; there's no need to train yourself into a thumb programmer just to prove remote development is viable.
Reconnection is similarly valuable. If the phone temporarily loses network or closes the page, you can reconnect to the session; as long as the relevant services and tasks on the work device are still running, you don't have to start over just because you changed access entrances.
What needs to be distinguished is that the phone disconnecting and the work device exiting are completely different. Computer sleep, Runtime crashes, or Connector stops all need to be handled separately. If a task is waiting for approval, it will still wait for your reply; it won't automatically get permission just because you switched to a phone.
Beginner onboarding: get a read-only task working first
Below is the flow for Mac mini + Claude Code + phone. For first use, I recommend connecting to the official service first, verifying a simple task, and only considering self-hosting once you're comfortable.
Step 1: Confirm the agent on your computer works normally
Prepare a computer that runs the task, plus a Claude Code, Codex, or DSH that is already configured with an account and works normally. Just pick the one you already have; you don't need to install all three just to try the workbench.
If Claude Code can't even complete an ordinary conversation on the computer, deal with its installation, login, or network issues first. A remote entrance being connected can't do the work for an agent that hasn't been set up.
Step 2: Download the client from the official entry point
Go to the project GitHub, choose the corresponding client from the download table in the README, or use the official download page.
| Your device | Entry point |
|---|---|
| Mac | macOS desktop client; official universal installer for Apple Silicon / Intel |
| Windows PC | Windows x64 desktop client |
| iPhone / iPad | App Store; TestFlight also offered, slots per invitation page |
| Android phone | Official APK |
| Browser | Web entry point for accessing connected work devices |
| Linux or headless server | Standalone Connector CLI, then operate through other clients |
Figure 5: Official download page; the screenshot selects Mac. On mobile, choose the platform that matches; specific installation requirements and download versions are subject to the official current instructions. Source: Official download page.
For the first installation, prefer following the current download entrance in the README; don't pick an old installer at random from historical releases. New features on the development mainline may not yet be in the release version you downloaded.
Step 3: Log in and connect the work device
Open the desktop client on the computer that runs tasks, choose to log in to Agents Anywhere Cloud, follow the browser-based guidance to complete login, then return to the app.
Follow the local device guidance to complete binding, and wait until the device shows online. The desktop client already includes the Connector; ordinary desktop users don't need to manually set up a connection service.
If you use a self-hosted service, fill in your own service address and log in. For a beginner's first try, you can skip this branch for now, so that instead of experiencing a tool, you end up creating an operations project for yourself.
Step 4: Choose a Runtime and project directory, send a test task
Once the device is online, select and configure the Runtime you want to use, for example Claude Code. Confirm it is available, then choose the project working directory and create a session.
The working directory is the project folder you want the agent to look at or operate on this time. If you choose the wrong directory, it may very earnestly analyze something and hand you a completely irrelevant answer.
You can start with this message:
Analyze the current project's code structure, find places that can be improved, give suggestions first, and don't modify files directly.
Once you see a normal reply in the timeline, continue to the next step. Using a read-only task to check the pipeline is much more reassuring than having it change configs or delete files the first time you connect.
Step 5: Log into the same service and account on your phone
Log in on the phone client or browser, select the connected Mac mini, and open the session from earlier. First see whether the reply from the computer is there, then add a follow-up question: "Can you explain the first issue you mentioned again?"
Here both the service and account must match. If the computer is connected to a self-hosted instance and the phone logs into Cloud, even similar account names should not lead you to assume both sides are the same set of devices and sessions.
The checkpoints for the whole flow are: device online, Runtime available, session receives a reply, phone can continue interacting.
If you get stuck, you can troubleshoot in the following order:
- Device not online: check whether the computer is powered on and networked, and whether the Connector is running normally.
- Device online but can't send tasks: continue checking the selected Runtime's configuration and error messages. Device online only means the connection service is up.
- Phone can't find the session: verify the service, account, and whether the computer side created the session under the corresponding device and project.
- Lost contact after leaving the desk: check system sleep and service exit. For long-running machines, arrange a background startup method.
Server users should also look at the official Connector CLI and background running instructions. Don't start multiple Connectors under the same system user and hope for the best; the official docs warn that they may contend with each other.
Already have SSH, or Claude's built-in remote feature? Do you still need it?
There are already plenty of remote access tools, and there's no need to give every new tool a "must install" slot.
| Option | Mainly solves | When to consider it first |
|---|---|---|
| SSH / Termius | Remote terminal login, run commands | Already comfortable with terminal, current workflow works |
| Remote desktop | Operate the entire computer's desktop | Need graphical software or a full desktop environment |
| Tailscale | Connect devices across different networks | Need to solve network access between devices first; it doesn't manage agent sessions itself |
| Claude Code Remote Control | Continue a local Claude Code session from another device | Mainly use Claude Code, needs centered on its sessions |
| Agents Anywhere | Manage multiple agents, sessions, files, and terminals across devices | Use several of Codex, Claude Code, DSH, or have multiple work devices |
If you only use Claude Code, it's worth also looking at its own Remote Control. If it meets your needs, there's no need to maintain another workbench just to reply to one sentence remotely.
If you're already comfortable with SSH and terminal session management, keeping your original setup is perfectly reasonable. The flexibility of the command line doesn't expire just because a new tool appears.
The scenario where Agents Anywhere is more convincing to me is when several devices, several agents, and several projects are mixed together: I want to find a task, see what it's doing, and then decide whether to go into files or a terminal. A purpose-built session interface is more convenient for handling this kind of thing on a phone.
It uses its own Client, Server, and Connector connection chain; SSH and Tailscale are not prerequisites that ordinary users must configure first. When choosing, you can look at network connection, terminal operations, and agent session management separately, without forcing several tools into a contest of who replaces whom.
Cost, privacy, and self-hosting: don't skip past "open source"
Model costs still follow the original tool
Agents Anywhere uses the existing agent environment and accounts on the work device. Model call costs follow the rules of the corresponding tool and account.
So installing this workbench does not automatically give you free credits for the models used by Claude, Codex, or DSH. You're just operating existing tools more conveniently; the bill won't feel too shy to arrive just because you looked at it from your phone.
Local execution should be separated from where data passes through
Code execution, file operations, and terminal commands happen on the work device where the Connector runs; the Server handles login verification, instruction forwarding, session saving, and attachment handling.
The official docs explicitly remind you that session content, timelines, code snippets, and attachments may pass through or be stored on the server side. Sensitive projects need to be evaluated accordingly; you can't see the words "executed locally" and take that to mean all data stays only on the local machine.
Self-hosting offers a choice, and brings maintenance work
The project uses the MIT open-source license and offers a Docker self-hosting solution. It can be roughly divided into four parts: the Client you operate, the Server responsible for connection and session services, the Connector on the work device, and the Agent Runtime that executes tasks.
After self-hosting, server-side data is handled by your deployed instance. Correspondingly, account permissions, network access, backup, and upgrades are also yours to manage. For people with sensitive data and clear management requirements, this option is very useful; for beginners who just want to experience phone takeover, you can first get the basic flow working.
The remote terminal also deserves serious attention. It uses the relevant permissions of the work device, and the consequences of a mistaken operation land on that machine. I suggest restricting unnecessary permissions, and when deleting files, deploying, or modifying important configs, first read the command and its scope. When an approval prompt appears, spending a few seconds reading it is friendlier than researching data recovery later.
Who would I recommend it to?
People who often let agents run longer tasks but can't conveniently stay in front of a computer can try it. It lets you handle those short interactions that stall progress after you leave your desk.
People with an always-on Mac mini or Linux server are also a good fit: the project and execution environment stay centrally on the work device, while laptops, phones, and tablets connect as needed.
If you also use Codex, Claude Code, and DSH at the same time, the benefit of unified device and session management is more obvious. However, this solves the hassle of finding tasks, checking progress, and continuing operations; how multiple agents divide up work is still something you arrange yourself.
Conversely, if you only use Claude Code occasionally, and tasks are short, the existing terminal or official remote features are enough, and not installing it for now costs you nothing.
My suggestion is to try one read-only task first: start an analysis from the computer, find the same session on the phone, ask a follow-up question, then return to the computer to check the result. Once that path runs smoothly, put longer tasks like refactoring and test fixes into it. As for cleaning the disk, first look at the paths, then click confirm.
Related links
- Project repo: https://github.com/anywhere-labs/Agents-Anywhere
- Official website: https://www.agents-anywhere.com/aa/en/
- Chinese official site: https://www.agents-anywhere.com/
- Client downloads: https://www.agents-anywhere.com/aa/download/
- Web access: https://web.agents-anywhere.com
- Official installation and first use: https://github.com/anywhere-labs/Agents-Anywhere/blob/main/docs/getting-started.md
- Self-hosting docs: https://github.com/anywhere-labs/Agents-Anywhere/blob/main/docker/README.md