How to Manage Multiple Coding Agents from Your Phone
Running more than one coding agent at a time? Grass lets you monitor all of them from a single mobile app — switching between sessions, handling approvals, and checking diffs.
If you are running two or three Claude Code sessions simultaneously — one migrating a database schema, one writing tests for a separate module, one exploring a bug in a third repo — Grass lets you monitor and control all of them from your phone. Each session is a separate server connection in the app. Switch between them with a tap, handle approval gates as they surface, and check diffs per repo without touching a keyboard.
TL;DR
- Grass supports multiple simultaneous server connections — one per
grass startinstance - Each connection appears in the app's server list; tap to switch between them
- Permission modals from any connected session surface automatically, regardless of which session you are viewing
- The global permission queue shows all pending approvals across all servers in one place
- Works with any combination of Claude Code and OpenCode sessions
Why running multiple agents creates a monitoring problem
Mobile coding agent orchestration — managing multiple agent sessions from a mobile device — is useful precisely because agents can work in parallel. A developer might run one agent on a backend refactor while another writes the frontend tests, compressing two sequential tasks into one time block.
The problem is attention. Each agent runs independently, and each can hit an agent approval gate at any point. If you are watching one terminal, you miss what the other agents are doing. If an agent waits for approval and you do not notice, it sits idle while the others make progress.
With a laptop, the best you can do is split your screen across multiple terminal windows — which still requires you to be at your desk and actively watching. Grass solves this for mobile by aggregating all sessions into one interface with a global permission queue that catches every pending approval regardless of which session triggered it.
How Grass handles multiple simultaneous sessions
Each grass start instance runs as an independent server on a different port in the 32100-32199 range. Multiple instances can run simultaneously — in different project directories on the same machine, or across entirely different machines.
In the Grass app, each server appears as a separate entry in the server list. You connect to each one by scanning its QR code or tapping a saved connection. From there:
Switching between sessions is a tap on the server list. Each server shows its own repository list, session history, and live chat view. You navigate between them the same way you would switch apps.
The global permission queue runs in the background across all connected servers. When any agent — on any server — requests approval to run a tool, a permission modal appears on your phone regardless of which session you are currently viewing. You do not need to be looking at the right server to catch an approval gate. The first pending request across all connected servers is always surfaced first.
Session persistence means each session keeps running independently of the others. If you are handling an approval on server A, server B's agent continues working. If your phone disconnects, all sessions keep running and replay missed output when you reconnect.
Step-by-step: setting up multiple agent sessions
Start the first session. In your first project directory, run
grass start. Note the port it selects (e.g.32100). Start a Claude Code session in that repo.Start a second session. Open a new terminal, navigate to a second project directory, and run
grass startagain. Grass auto-selects the next available port (e.g.32101). Start a Claude Code or OpenCode session there.Repeat for additional sessions. Each
grass startinstance gets its own port. Up to 100 instances can run simultaneously within the32100-32199range.Scan each QR code with the Grass app. Open Grass, tap the QR scanner, and scan the QR code for each server. Each connection is saved in your server list.
Monitor from the server list. The server list shows all your active connections. Tap any server to see its sessions, open a chat, or check diffs.
Handle approvals as they appear. Permission modals appear automatically when any agent needs approval. Approve or deny with one tap — you do not need to navigate to the right server first.
Running agents across multiple machines or Daytona workspaces
Multiple sessions do not have to run on the same machine. You can connect Grass to agents running on entirely separate machines — one on your laptop, one on a transient dev server like Daytona, one on a remote VM. Each server connection in the Grass app is independent.
This is useful when different tasks have different compute requirements. A large codebase migration might benefit from a beefy Daytona workspace; a smaller test-writing task can run locally. Both agents appear in the same Grass server list, and both funnel approval gates into the same global permission queue.
For remote connections, use grass start --network tailscale on the remote machine to generate a Tailscale-IP QR code, or grass start --network remote-ip for public IP access. The Grass app handles multiple connection types simultaneously — local and remote servers coexist in the same server list.
What you need
- Grass CLI —
npm install -g @grass-ai/ide(Node.js 18+ required), installed on each machine running an agent - Grass mobile app — iOS App Store (native) or Android PWA
- Claude Code or OpenCode — installed and authenticated on each machine
- Separate project directories — each
grass startinstance should be run from its own directory; the repo list reflects subdirectories of wherevergrass startis run - Pricing — free for local use; Daytona remote usage includes free credits
Frequently asked questions
How many simultaneous sessions can Grass handle?
Grass auto-selects ports from the range 32100-32199, which means up to 100 grass start instances can run simultaneously on a single machine. In practice, the limit is your machine's available compute rather than Grass's port range. There is no hard limit on the number of server connections in the mobile app.
If two agents hit approval gates at the same time, which one surfaces first?
The global permission manager surfaces the first pending request it receives. If two approval gates arrive simultaneously, one will appear first based on which arrived in the queue first. After you handle it, the next pending modal appears immediately. You cannot miss an approval gate — they queue rather than disappear if you do not act on them right away.
Can I mix Claude Code and OpenCode sessions in the same Grass app?
Yes. Each session in the Grass app has its own agent selection — Claude Code or OpenCode — chosen when the session is created. You can have one server running Claude Code and another running OpenCode, both visible in the same server list and both funnelling approval gates into the same global permission queue.
Does the Grass app show me which server triggered an approval gate?
Yes. The permission modal includes the server, repository, and agent context so you know which session is requesting approval. You do not need to guess or navigate to the right server — the modal tells you exactly what is asking and what action it wants to take.
What happens to other sessions when I approve an action on one?
Nothing — the sessions are fully independent. Approving an action on server A has no effect on the agents running on server B or server C. Each agent continues its own task on its own timeline. The only shared resource is the global permission queue, which surfaces each approval in sequence.
Can I close the Grass app and still get approval notifications?
Grass does not currently send push notifications — approval gates appear as in-app modals, which means you need to have the app open to see them. If you close the app, approval gates queue on the server side and surface the next time you open Grass and reconnect. The agent waits for your approval rather than timing out.
Related use cases
Monitor a long-running coding agent overnight — The single-session monitoring workflow in detail. Good starting point before scaling to multiple sessions.
Connect Grass to Daytona — How to run an agent on a Daytona remote workspace and connect it to Grass. Relevant for multi-session setups where different tasks run on different infrastructure.
Approve or deny a coding agent action from your phone — A closer look at the permission modal itself: what triggers it, what information it shows, and how to handle a backlog of pending approvals.