Async Agent Workflows: Notifications, Approvals, and Handoffs

Quick answer

An async agent workflow lets AI coding agents run on your real computer while you’re away, notifying you only when they need input, hit a limit, or finish a task. You approve, unblock, or redirect them from your phone—no SSH, no cramped mobile IDE—then let them continue working until the next checkpoint.

Key takeaways

• Async means agents work independently: they run on your desktop while you’re mobile, notifying you only when blocked or needing approval.
• Approval gates keep agents safe: you decide which actions require your sign-off and which can auto-approve.
• Handoffs between surfaces: start a conversation in Claude Desktop, approve from your phone, finish the review in your IDE.
• Multi-lane workflows: run several agents in parallel across git worktrees or related folders without conflicts.
• Email loops: continue or start agent conversations directly from your inbox when push notifications aren’t enough.
• Notifications are your dashboard: configure alerts for “needs approval,” “hit quota,” or “needs re-auth” so you only intervene when necessary.

---

Why Async Matters: Agents That Work While You’re Away

In 2026, developers build by directing AI coding agents, not typing every line. The shift from synchronous to async agent workflow is the difference between babysitting a chatbot and managing a team: you give an agent a task, let it run, and check back when it needs you.

Synchronous workflows require you to sit at your desk, watch the agent’s output, and respond immediately. That’s fine for a quick fix, but it doesn’t scale when you’re triaging from a coffee shop, answering a Slack ping, or just away from your machine. Async coding agents run on your real computer—your macOS Apple Silicon or Windows 10+ desktop with its filesystem, terminal, and tools—while you’re mobile. They notify you when they hit a decision point, a quota limit, or need re-authentication. You approve, unblock, or redirect them from your phone, then let them continue.

This isn’t a cloud sandbox or a remote-desktop stream. The work runs on your own machine. A lightweight Desktop Connector—a native tray or menu-bar app—pairs your desktop and exposes it through a private, per-desktop tunnel secured by a short-lived connect token. Your phone reaches the desktop through that tunnel. Agent history and local project files stay on your computer unless you deliberately send content to an agent or provider. MobileVibe’s cloud stores desktop routing and session metadata, not your raw conversation history or project directories.

The object you care about is a conversation: one agent chat or thread tied to a folder, an agent (Claude, Codex, Cursor, Windsurf), and a surface (CLI, IDE, or extension). Your dashboard becomes an inbox of what needs attention—what’s blocked, what’s still working, what changed, and what can be safely resumed from a phone.

---

Setting Up Notifications So You Know When an Agent Needs You

Notifications are the backbone of an async agent workflow. Without them, you’re either polling your desktop every ten minutes or missing the moment an agent hits a quota, needs approval, or finishes a task.

Push and email alerts tell you when a conversation changes state:

• Needs approval: the agent wants to run a command, write a file, or make a change you’ve gated.
• Needs input: the agent is waiting for you to answer a question or provide context.
• Hit a quota: the agent exhausted its rate limit or token budget.
• Needs re-auth: the agent’s session expired or lost credentials.
• Finished: the agent completed the task and is idle.

You configure these alerts per conversation or globally. For example, you might want push notifications for “needs approval” but only email for “finished” tasks. The goal is to intervene only when necessary, not to recreate the constant-interruption loop of synchronous work.

Auto-approve controls (where supported by the agent) let you pre-authorize certain actions—like running tests, formatting code, or writing to a specific directory—so the agent doesn’t block on routine decisions. This is the difference between “approve every file write” and “approve only when the agent touches production config.”

When a notification arrives, you open the conversation on your phone, see the agent’s request, and approve or reject it. The agent continues from that checkpoint. You don’t need to SSH back to your desktop or open a cramped mobile IDE.

---

Approval Gates: Letting Agents Run Safely Without Constant Oversight

Approval gates are the trust boundary between “let the agent run” and “I need to review this first.” They’re essential for async coding agents because you’re not watching every step.

What to gate:

• File writes outside the project directory: if the agent wants to touch ~/.bashrc or /etc/hosts, you probably want to approve that.
• Network requests to unfamiliar endpoints: if the agent is calling an API you didn’t mention, pause and check.
• Shell commands with sudo or rm -rf: obvious red flags.
• Changes to production config or deployment scripts: anything that could break a live system.

What to auto-approve:

• Test runs: npm test, pytest, or cargo test are usually safe.
• Linting and formatting: prettier, black, or rustfmt don’t change logic.
• Writes to a designated scratch directory: if you’ve told the agent to work in ./tmp or ./experiments, let it go.
• Reads and analysis: the agent can read any file in the project without approval.

The agent approval setup varies by tool. Claude Desktop and the Claude CLI support approval prompts natively; you configure them in the agent’s settings or via environment variables. Codex (both the IDE extension and MobileVibe’s native headless codex-cli) has similar controls. Cursor and Windsurf are separate host apps with their own approval models—check their docs for specifics, and note that full history enumeration or Claude-like surface switching should not be assumed.

When an agent hits an approval gate, it pauses and sends a notification. You review the request on your phone, see the diff or command, and approve or reject. The agent resumes from that point. If you reject, you can provide feedback or redirect the agent to a different approach.

---

Handoffs Between Agents and Surfaces: Resume From Phone, Finish on Desktop

An agent handoff workflow is when you start a conversation in one surface, approve or redirect it from your phone, and finish the review in another surface. This is where async agent workflow shines: the agent’s work persists across contexts, and you pick the right tool for each step.

Example handoff:

1. Start in Claude Desktop: you give Claude a task—“refactor this module to use async/await”—and let it run while you step away.
2. Approve from your phone: Claude hits an approval gate (wants to rewrite a core file). You get a push notification, open the conversation on your phone, review the diff, and approve.
3. Finish in your IDE: later, you’re back at your desktop. You open the conversation in your IDE (VS Code, Cursor, or Windsurf), review the full changeset, run tests, and commit.

Provider nuances:

• Claude IDE and CLI can share the native Claude store, so cross-surface resume is comparatively cheap. You can start a conversation in the CLI, approve from your phone, and open it in Claude Desktop without copying history.
• Codex has a separate IDE extension and MobileVibe’s native headless codex-cli. Moving history between them may require copying or forking the conversation. This is fine for handoffs but not as seamless as Claude’s shared store.
• Cursor and Windsurf are separate host apps, not VS Code aliases. Full history parity or Claude-like surface switching should not be assumed. If you start a conversation in Cursor, you may need to export or summarize it to continue in Windsurf.

The key is that the agent’s work—the files it changed, the commands it ran, the context it built—stays on your desktop. You’re not moving the work to a cloud IDE or a remote-desktop session. You’re just changing how you interact with the agent.

---

Multi-Lane Workflows: Running Several Agents in Parallel Across Worktrees

Multi-lane workflows are when you run several agents in parallel across related folders or git worktrees. This is common when you’re prototyping multiple approaches, working on a feature and a bugfix simultaneously, or splitting a large task into independent subtasks.

Why worktrees: a git worktree is a separate checkout of your repo, tied to a different branch or commit. Each worktree has its own working directory, so agents don’t step on each other’s files. You might have:

• main-worktree/ (the stable branch)
• feature-async-worktree/ (the feature you’re building)
• bugfix-auth-worktree/ (a hotfix you need to ship)

Each worktree is a separate folder, so you can run a separate agent conversation in each. The agents don’t conflict because they’re writing to different directories.

How to manage lanes:

1. One conversation per folder: each agent conversation is tied to a folder. If you have three worktrees, you have three conversations.
2. Name your conversations clearly: “feature-async: implement retry logic” and “bugfix-auth: fix token refresh” are easier to triage than “conversation 1” and “conversation 2.”
3. Use notifications to prioritize: if one agent is blocked and another is still working, you know which to check first.
4. Merge carefully: when agents finish, you review their changes in your IDE, run tests, and merge. Don’t let agents merge automatically unless you’ve gated that action.

Common pitfall: running two agents in the same folder. If both agents try to write to the same file, you’ll get conflicts. Use worktrees or separate project directories to avoid this.

---

Handling Quota Limits, Re-auth, and Blocked Agents From Mobile

Quota limits and re-authentication are the two most common reasons an agent blocks while you’re away. Both are solvable from your phone.

Quota limits: most AI providers (Anthropic, OpenAI, etc.) have rate limits or token budgets. If an agent exhausts its quota, it pauses and sends a “hit quota” notification. You have three options:

1. Wait: if the quota resets in a few minutes, just let the agent sit. It’ll resume automatically when the limit lifts.
2. Switch providers: if you have a backup API key or a different provider, you can redirect the agent to use that.
3. Upgrade your plan: if you’re hitting quotas regularly, it’s time to increase your tier.

Re-authentication: if an agent’s session expires or loses credentials, it sends a “needs re-auth” notification. You open the conversation on your phone, see the error, and re-authenticate. This might mean:

• Logging in again: if the agent uses OAuth, you’ll get a login prompt.
• Refreshing a token: if the agent uses an API key, you might need to paste a new one.
• Restarting the agent: sometimes the simplest fix is to stop and restart the conversation.

Blocked agents: if an agent is stuck—waiting for input, hitting an error, or looping—you get a notification. You open the conversation, see the context, and either:

• Provide input: answer the agent’s question or clarify the task.
• Redirect: tell the agent to try a different approach.
• Cancel: if the agent is off-track, stop it and start a new conversation.

All of this happens from your phone. You don’t need to SSH back to your desktop or open a terminal. The agent runs on your real machine, but you control it from a mobile-friendly UI.

---

Email Loops: Continue or Start Agent Conversations Without Leaving Inbox

Email loops are an alternative to push notifications when you’re not actively monitoring your phone or prefer to triage from your inbox.

“Email this conversation” continues an existing conversation. The agent sends you an email with the current state, any pending approvals, and a link to resume. You reply to the email with your input or approval, and the agent continues from that checkpoint. This is useful when:

• You’re in a meeting and can’t open the app.
• You want a record of the conversation in your email.
• You’re triaging multiple agents and prefer to batch your responses.

“Email this project” starts a new conversation in a specific folder. You send an email with the task description, and the agent starts working in that project. This is the fastest way to kick off a new task without opening the app.

Security note: never send secrets, passwords, or API keys through email. If an agent needs credentials, provide them through the app or a secure environment variable.

---

Common Pitfalls: When Async Workflows Stall and How to Unblock Them

Async agent workflow is powerful, but it’s not foolproof. Here are the most common stalls and how to fix them:

1. Agent is waiting for input you didn’t see: you missed the notification or the agent’s question was ambiguous. Check the conversation history, provide the missing context, and resume.
2. Approval gate is too strict: you’ve gated every file write, so the agent blocks constantly. Loosen the gates for routine actions (tests, formatting) and tighten them for risky ones (production config).
3. Agent is looping on the same error: it tried the same fix three times and failed each time. Stop the agent, review the error, and redirect it to a different approach.
4. Two agents are conflicting: you ran two agents in the same folder, and they’re both trying to write to the same file. Use worktrees or separate directories to isolate them.
5. Agent hit a quota and you didn’t notice: the “hit quota” notification went to email, not push, and you didn’t check. Configure push notifications for critical events.
6. Agent’s session expired: the agent needs re-auth, but you’re not near your desktop. Re-authenticate from your phone using the app’s auth flow.

The fix is almost always: check the conversation, see what the agent needs, and provide it. The agent is running on your real machine, so you have full context—file diffs, terminal output, error logs—available from your phone.

---

FAQ

What’s the difference between an async agent workflow and a synchronous one?

A synchronous workflow requires you to sit at your desk and respond immediately to every agent prompt. An async agent workflow lets the agent run on your desktop while you’re away, notifying you only when it needs input, hits a limit, or finishes a task. You approve or unblock it from your phone, then let it continue.

How do I know when to approve an agent’s work versus letting it auto-approve?

Gate risky actions—file writes outside the project, shell commands with sudo, changes to production config—and auto-approve routine ones like test runs, linting, or writes to a scratch directory. The goal is to let the agent work independently without risking your system or data.

Can I really control an agent from my phone, or do I need to SSH back to my desktop?

You control the agent from your phone through MobileVibe’s mobile-friendly UI. No SSH, no cramped mobile IDE. The agent runs on your real desktop, and your phone reaches it through a private, per-desktop tunnel. You see the agent’s requests, approve or reject them, and let it continue—all from your phone.

What happens to my agent’s history and local files if I use MobileVibe?

Agent history and local project files stay on your own computer unless you deliberately send content to an agent or provider. MobileVibe’s cloud stores desktop routing and session metadata, not your raw conversation history or project directories. Your work never leaves your machine.

How do I set up multiple agents to work on related tasks without them stepping on each other?

Use git worktrees or separate project directories. Each agent conversation is tied to a folder, so if you have three worktrees, you have three isolated agents. They don’t conflict because they’re writing to different directories. Name your conversations clearly and use notifications to prioritize which agent needs attention first.

What should I do if an agent hits a rate limit or needs re-authentication while I’m away?

You’ll get a notification. Open the conversation on your phone, see the error, and either wait for the quota to reset, switch providers, or re-authenticate. All of this happens from your phone—no need to SSH back to your desktop.

Can I resume a conversation started on my desktop from my phone?

Yes. The conversation runs on your desktop, but you access it from your phone through MobileVibe. You can start a task in Claude Desktop, approve it from your phone, and finish the review in your IDE. Claude IDE and CLI can share the native Claude store, so cross-surface resume is comparatively cheap. Codex and other agents may require copying or forking the conversation.

How do notifications work, and can I customize when I get alerted?

You configure notifications per conversation or globally. Push and email alerts tell you when an agent needs approval, needs input, hits a quota, needs re-auth, or finishes a task. You decide which events trigger push versus email, so you only intervene when necessary.

---

Ready to run agents while you’re away? MobileVibe lets you control AI coding agents on your real computer from your phone—approve, unblock, and resume conversations without SSH or a cramped mobile IDE. Start free at mobilevibe.com and turn your desktop into an async agent powerhouse.