Run tasks from your phone

snaga connect links a machine to your account. After that, the web app and the mobile apps can send it tasks — and the work happens on that machine, in the directory you started it from, with your toolchain and your files.

The phone is a remote control, not a runtime. Nothing about your repository is copied somewhere else to be worked on.

Connect a machine

cd ~/projects/my-app
snaga connect

It prints what it registered and then waits:

  >>> Snaga Bridge Agent
  Agent ID:     …
  Status:       online
  Working dir:  /Users/you/projects/my-app
  Capabilities: N tools registered
  Peers:        no other bridge agents online
  Polling for tasks... (Ctrl+C to stop)

The working directory is fixed at connect time. To offer a different project, stop it and connect again from there — one connected agent serves one directory.

If you have connected more than one machine, each lists the others under Peers, with the directory each is serving. That is how you tell the laptop from the workstation when you are choosing where to send a task.

Ctrl+C disconnects. The connection is a poll loop with a heartbeat every 15 seconds; if the network drops, it backs off and retries, from one second up to a minute between attempts, rather than giving up.

What reaches the connected agent

A task carries your message and the prior conversation, so the agent can reconstruct the thread before it starts on the new instruction.

Files attached to a message can reach the agent too, on some paths and not others, with the bytes landing on disk rather than in the conversation. That has enough conditions attached to deserve its own page — see Attachments.

Long tasks

A bridge turn gets a wall-clock ceiling of 15 minutes, against 5 minutes for an interactive session — a task sent from a phone is likely to be one nobody is watching. Time spent waiting for an approval does not count against it, so a task does not expire because you were slow to tap Approve.

Raise it when a job legitimately needs longer. Note the flag order — this is a top-level option, so it goes before the subcommand:

snaga --turn-timeout 3600 connect

What you see while it runs

Progress streams back to whichever client sent the task: the agent's reasoning, each tool call, and the result. A failed task carries the reason it failed rather than an empty error — and if something goes wrong that the agent itself should know about, it is told in its own prompt, not just logged for you.

Related

• Approvals and safety — what happens when the agent wants to do something dangerous and you are not at the keyboard
• Permissions and safety — the local rules that apply in every mode