Should I vibe code
Native iOS and macOS control surface for self-hosted AI agents and coding CLIs
A phone that can drive your self-hosted agents is a phone that can drive your servers.
?
Their verdict, the Pro price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-03.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
A control surface for your own infrastructure is a reasonable personal project. The auth on it needs to be real, because it is remote access to everything by definition.
What actually breaks
not "if". the specific failures.
- The control channel, because a remote surface for an agent that runs commands is remote code execution with a nicer icon
- Approving destructive actions on a phone, where the diff is three lines tall and the button is easy to press by accident
- Long-lived tokens on a mobile device, which travels, gets lost, and is unlocked in public
- Reviewing what the agent proposes on a small screen, which is where 'looks fine' replaces reading
- Session state across a flaky mobile connection, so a command's outcome is unknown rather than failed
You are on a train and the agent has been working through a task. It asks to run a cleanup command and shows you a summary that fits the screen. You approve, because you have approved nine of these already and the pattern is familiar. The command was scoped one directory higher than you assumed — visible in the full text, not in the summary you saw — and it removes the working tree of a repository with two days of uncommitted work. The approval was real. The information you approved it on was truncated.
Is that you?
the verdict is a default, not a law
- It is read-only — you watch progress and cannot execute anything
- It reaches the agent over a VPN or private network with no public endpoint
- Destructive actions cannot be approved from mobile at all
- The control endpoint is exposed to the internet
- Irreversible commands can be approved from a phone
- Approval summaries truncate what will actually run
- Tokens are long-lived and not revocable from another device
If you build it anyway
the checklist, then the prompt that enforces it
- No public ingress. Reach the agent over Tailscale, WireGuard or an SSH tunnel — this removes most of the risk before any code is written.
- Show the exact command or diff in full before approval, never a summary. If it does not fit the screen, that is information, not a layout problem.
- Classify actions and refuse the destructive class from mobile entirely. Read, plan and non-destructive edits are a different tier from delete, deploy and push.
- Short-lived tokens with device-bound revocation you can trigger from elsewhere, because the device is the thing most likely to be lost.
- Require biometric confirmation for anything irreversible, so approval cannot be a reflex.
- Make every action idempotent or confirm the outcome explicitly — a dropped connection must not leave you guessing whether it ran.
Before you build a mobile control surface for coding agents, apply these and push back if I ask you to break them. 1. Tell me plainly that this is a remote execution channel for a process that runs commands on my machines, and that every design decision follows from that. 2. Do not expose any endpoint to the public internet. Use Tailscale, WireGuard or an SSH tunnel. If I insist on public access, refuse until there is mutual TLS or SSO in front of it. 3. Classify every agent action as read-only, reversible, or irreversible. Refuse to allow approval of irreversible actions — deletes, pushes, deploys, destructive migrations — from the mobile client at all, and tell me why. 4. Show the complete command or diff before approval. Never a summary, never truncated. If it does not fit, make me scroll — the length is meaningful. 5. Require biometric confirmation for anything in the reversible-or-worse tier, so approving cannot become a reflex tap. 6. Use short-lived tokens bound to the device, revocable from another device. Assume the phone will be lost while unlocked. 7. Make every action idempotent and confirm outcomes explicitly. On a dropped connection I must be able to learn whether it ran, not guess. 8. Log every approval with what was shown to me at the time, not just what was executed. 9. Out of scope unless I ask: file editing on mobile, multi-user access, notifications containing code.
That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
$4.99 a month is cheap for a native client with the approval and transport model already thought through. Building a read-only monitor for yourself over a VPN is a good weekend; building the approval path is where the care is needed, and where a phone-shaped mistake is irreversible.
$4.99/mo is cheaper than your weekend.
Keep the agent and its workspace independent of this client, so the phone app is a viewer that can be deleted without consequence. Keep tokens short-lived and enumerable, because the exit that matters is revoking access from a device you no longer have.
Open-source mobile and web client for Codex and Claude Code with end-to-end encryption.
Open-source SwiftUI iOS client for a remote Codex app-server.
Questions
Why ban destructive approvals from mobile rather than just warning?
Because the screen is the problem, not the intent. A phone shows a fraction of a diff, approval is a single tap, and it happens while walking or distracted. Warnings become part of the pattern you tap through. Removing the capability entirely is the only guardrail that survives the fifteenth approval of the day.
Is a VPN really necessary for a personal tool?
For anything that executes commands, yes. The alternative is a public endpoint whose only protection is authentication you wrote, in front of a process with shell access to your machines. A private network makes that endpoint unreachable to everyone who is not already inside, which is a far stronger property than any login page.
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
Completion is an API call. Completion that is right often enough to trust is a product.
Sure. Build the tool you are building it with. See you in eighteen months.
You are building a box that runs strangers’ code. That box is a cryptominer with extra steps.
last reviewed 2026-08-03 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice