Mobile and remote delegation

Remote control surfaces the community describes as “Codex from a walk” or “fix tests via Telegram”:

• Delegated runs: trigger tests, linters, or packaging on a machine you control.
• Status threads: progress every N iterations, logs attached, clear done/fail.
• Cross-device continuity: start on phone, continue on desktop without re-explaining the repo.

This is not “replace your IDE”—it is orchestration and visibility when you are away from the desk.

• Channels map naturally to “message like a coworker” UX.
• Timelines and artifacts show what ran—critical when you are not watching the screen.
• Sandboxing and approvals reduce the chance of remote-triggered destruction.
• Multi-provider routing fits “cheap model for triage, strong model for the hard part.”

1. Define allowed commands remote users (you) may trigger.
2. Require branch isolation—no direct pushes to protected branches from automation.
3. Stream incremental output so long runs do not look hung.
4. Cap concurrency so three phones do not start three full builds.
5. Alert on failure with enough context to fix from mobile.

• Stable network path to the runner (VPN, tailscale, or SSH host as appropriate).
• Identity: ensure only you can trigger expensive or destructive jobs.

1. Dry-run a harmless command from the messenger surface.
2. Add test or lint jobs with short timeouts.
3. Add build jobs with artifacts you can inspect from chat.
4. Harden secrets: env injection, not pasted keys.
5. Retrospective after first week: what failed silently?

• “What evidence will you post if tests fail?”
• “Refuse to run if working tree is dirty—explain why.”
• “Summarize blast radius before starting this job.”

• Kill switch tested from the phone interface.
• Cost limits understood for cloud minutes or API calls.
• Teammates know this is your runner, not shared prod.

• Long-running jobs that drain battery or money unattended.
• Ambiguous natural language triggering the wrong script.
• Leaking repo paths or customer names into chat logs.