Remote Control: Mobile Companion App

[kvnloo]

📱 RFC: Mobile Companion App for Auto-Claude

The Problem

We've all been there: you kick off an autonomous build, walk away to grab coffee or run an errand, and then spend the next hour wondering:

• Did it finish?
• Is it stuck on a permission prompt?
• Did QA pass or is it looping?

Auto-Claude is designed for autonomous, long-running tasks—but we're still tethered to our desks to monitor them. The irony is that the more autonomous the tool becomes, the more we should be able to step away. But right now, stepping away means flying blind.

The Proposal

A mobile companion app that turns your phone into a remote control for Auto-Claude:

Core Features (MVP)

• Live task monitoring — See active specs, current phase, and progress in real-time
• Push notifications — Get alerted on completion, QA failures, or when human input is needed
• Task queue management — Add new tasks to the queue without returning to your desk
• Session logs — Scroll through agent output on your phone

Stretch Goals

• Approve/reject QA results remotely
• View git diffs before merge approval
• Terminal access for manual intervention
• Multi-project dashboard

Technical Approach

I'm proposing Tauri 2 Mobile for cross-platform support (Android + iOS from a single Rust/React codebase). This aligns with Auto-Claude's existing tech choices and keeps the stack cohesive.

Connectivity: Rather than building relay infrastructure, I'm proposing Tailscale for direct, encrypted connections between your phone and workstation. This means:

• Zero server costs (no relay to host)
• Lower latency (P2P, not hopping through a middleman)
• Works anywhere (home, coffee shop, mobile data)
• Self-hosted = you control your data

Why This Matters

Auto-Claude already solves the "I want AI to code for me" problem. This solves the "I want AI to code for me while I live my life" problem.

For power users running multiple parallel agents across projects, this becomes even more valuable—a single dashboard to monitor everything, from anywhere.

Prior Art & Inspiration

• Happy Coder — Similar concept for vanilla Claude Code, but uses a public relay server
• Replit Mobile — Full cloud IDE on mobile (different philosophy, but great UX reference)

What I'm Looking For

1. Interest check — Is this something the community wants?
2. Feedback on scope — Is the MVP right-sized? Too ambitious? Missing something critical?
3. Technical input — Better connectivity approaches? Concerns with Tailscale dependency?
4. Collaborators — Anyone want to help build this?

I've already done some initial planning and have a draft PRD. Happy to share more details or start a working group if there's interest.

---

I ran this by the Discord and got initial support. Posting here to open it up for broader community input before diving into implementation. I believe that we will need to create a dedicated API with swagger support to get started.

[AndyMik90]

@kvnloo Been wanting this myself :D I have noted it as a feature for 2.9.0 version as it should rely on the new infrastructure of the cloud/web app.

[buffcode]

Strong +1 on decoupling connectivity from the product and going fully headless-first.

The core issue here isn’t “mobile vs desktop” or even “remote monitoring” — it’s that Auto-Claude currently conflates execution, UI, and network topology. That’s what’s creating friction and premature constraints (e.g. Tailscale assumptions).

Headless Auto-Claude as the foundation

Auto-Claude should run as a headless service with a well-defined API.
The existing UI (desktop today, mobile tomorrow) becomes just another client.

Key implications:

• No baked-in assumptions about how you connect
• No opinionated VPN choice
• Clean separation of concerns
• Enables far more than just a mobile app

This aligns perfectly with your goal of “AI runs while I live my life”, without locking users into a single networking strategy.

API-first architecture (suggested)

• Auto-Claude runs as a local or remote daemon

• Exposes a versioned HTTP/WebSocket API

• UI connects to a configurable endpoint

• Endpoint is:

  • auto-discovered on first run (default: localhost)
  • overrideable later (settings, env var, config file)

From there, users choose their own transport:

• Tailscale
• Zerotier
• Cloudflare Tunnel
• Plain LAN
• SSH port-forward
• Kubernetes ingress
• Anything else

Auto-Claude doesn’t care. That’s the point.

Mobile app becomes trivial (and optional)

Once the API exists:

• Mobile companion app is just another client
• Desktop UI can reuse the same API
• CLI tooling can reuse it
• Third-party dashboards become possible
• Power users can script against it

At that point, Tauri vs native vs web becomes an implementation detail, not a blocker.

Notifications & long-running tasks

With a headless server:

• WebSockets / SSE for live task state

• Event stream for:

  • task completed
  • QA failed
  • human input required

• Push notifications handled entirely client-side (mobile OS, browser, etc.)

No relay infrastructure required by default — but not forbidden either.

Why not bake in Tailscale?

Tailscale is great — but:

• It’s an opinionated dependency

• It excludes users with:

  • corporate VPN conflicts
  • locked-down devices
  • existing infra preferences

• It leaks networking decisions into product design

If someone wants Tailscale, they can add it in 5 minutes.
If they don’t, they shouldn’t have to fight the tool.

This also future-proofs Auto-Claude

Headless + API unlocks:

• Remote Auto-Claude on beefy servers
• Multiple agents across machines
• Shared dashboards across teams
• Hosted offerings later (if ever desired)
• CI/CD-style automation

All without revisiting core architecture.

MVP scope feedback

The MVP you outlined is solid, but I’d reframe it slightly:

True MVP

• Headless Auto-Claude daemon
• Read-only task/state API
• WebSocket/SSE for live progress
• Configurable endpoint in UI

Phase 2

• Task submission
• Human-in-the-loop prompts
• Notifications

Phase 3

• QA approval
• Git diffs
• Terminal access (danger zone, but powerful)

Mobile app can start at Phase 1 and grow naturally.

TL;DR

• Headless Auto-Claude + API should be the foundation
• UI connects to a configurable, auto-discovered endpoint
• Networking is user-defined, not product-defined
• Mobile app becomes easy, optional, and powerful
• This solves more than the original proposal, with less lock-in