PocketVeto Is a Bluetooth Agent Remote

pocket-veto is a small open-source project maintained under the pocket-veto GitHub organization that turns an Android phone into a Bluetooth approval remote for AI coding agents. It deals with the boring but important moment when an agent wants to run a risky command, write files, or call an MCP tool while you are away from the keyboard. The takeaway is simple: agent safety is not only about smarter models; it is also about where the stop button lives. It also gives a concrete answer to the workflow question behind “what is cursor agent”: an agent is useful when its actions are visible, bounded, and easy to interrupt.

A Cursor agent is the coding assistant inside Cursor, Anysphere’s AI code editor, that can inspect a repo, edit files, run commands, and work through a task with user-controlled context. PocketVeto is not a Cursor feature, but it pokes at the same pressure point Cursor users feel every day: approvals should be fast enough that you do not disable them, and explicit enough that you do not sleepwalk through them.

Watch the approval boundary, not just the chat

PocketVeto’s core idea is local and physical. The host machine owns the Bluetooth radio, the phone pairs over Bluetooth Classic, and the phone becomes both an approval gate and a live progress dashboard.

That matters because agent work often fails at the boundary, not in the prompt. A Cursor agent can draft a migration, update tests, and propose a shell command; the scary part is deciding whether the next command is routine or destructive.

As of July 2026, the project describes v1 support for Windows, native Linux, and Linux devcontainers through a host-sidecar pattern. macOS Bluetooth support is deferred, though the non-Bluetooth parts compile and run on macOS according to the repository notes.

The trap is treating a phone button as magic security. A remote veto helps only if the request is legible: command, working directory, target files, and reason. If the phone just says “approve?” you have moved the rubber stamp from your desk to your pocket.

Bluetooth is the little hack people noticed

The charming part of PocketVeto is that it avoids the usual remote-control stack. No web dashboard. No LAN routing. No dependency on Wi-Fi working cleanly through AP isolation.

The author’s stated itch came from seeing small ESP32 hardware dashboards for coding agents and wondering whether a phone could do the same job with less gear. Bluetooth is not glamorous, but it has the right shape for a local approval loop: nearby, paired, and not exposed to the internet by default.

That is why the project landed as a Hacker News curiosity rather than another agent dashboard. It answered a real desk problem: you start an agent, walk away, and then the work stalls on a permission prompt you cannot see.

The limitation is also obvious. Bluetooth behavior varies by operating system, and the project itself calls out rough edges on Linux and non-working macOS Bluetooth support for v1. If your workflow depends on a Mac laptop as the Bluetooth host, this is not ready as a daily driver.

Put the same boundary into Cursor work

Cursor users do not need to adopt PocketVeto to learn from it. The useful move is to make approval boundaries explicit before you let Cursor agents touch risky surfaces.

Cursor rules are a good place to write those boundaries because they travel with the repo and can be scoped to files or folders. For deeper reusable workflows, the related training topic covers cursor subagents, cursor skills, rules, and MCP as separate pieces instead of one giant prompt.

Here is a small .mdc rule stub for a repo where agent commands are allowed, but destructive actions need a pause:

---
description: Require review before risky local actions
globs:
  - **/*
alwaysApply: true
---

Before running commands that delete files, rewrite history, change database state, rotate secrets, or call external MCP tools with write access, stop and ask for approval.

When asking, include:
- the exact command or tool call
- the working directory
- the files or services affected
- the rollback plan, if there is one

Do not summarize destructive commands as “cleanup” or “update”. Show the action plainly.

That rule does not replace review. It gives the Cursor agent a crisp boundary so the review can happen before the expensive mistake.

The trap is stuffing every preference into one always-on rule. Keep durable rules small. Put task-specific context in the chat, and put reusable procedures into cursor skills when the workflow has real steps, scripts, or reference material.

Try PocketVeto when distance is the problem

PocketVeto makes sense when the bottleneck is physical distance from the machine running agents. A devcontainer on a Linux host, a Windows workstation in the next room, or a long-running refactor where you mostly need to approve or deny tool use are plausible fits.

It is overkill if your Cursor agent workflow already stays inside the editor and you are actively reviewing each step. It is also the wrong fix if the real problem is vague permissions, broad MCP access, or agents running with more repository rights than they need.

A good first experiment is narrow. Pick one repo, one host, and one class of risky action. For example: allow the agent to edit tests freely, but require explicit approval before shell commands that touch the database or delete generated assets.

If you are comparing adjacent local-agent ideas, local-motion Runs Cursor Agents Locally is a useful companion read. PocketVeto is about the approval surface; local execution is a different question.

Starter checklist for trying it safely

Use this as a lightweight fit check before you wire any approval remote into real coding work.

• Confirm your host OS matches the project’s current support: Windows, native Linux, or Linux devcontainer via host sidecar.
• Start with a throwaway repo or a branch you can reset quickly.
• Define one risky action class: shell commands, file writes, or MCP calls.
• Make approval prompts show the exact command, path, and affected files.
• Keep write-capable MCP tools out of the first test.
• Add a Cursor rule that tells the agent when to stop and ask.
• Run one boring task first, such as updating tests after a small API rename.
• Deny at least one request on purpose to verify the failure path is clear.
• Check what the phone dashboard shows while the agent is running.
• Stop if approvals become vague, repetitive, or too easy to tap through.

The quiet win is not approving from a sofa. The win is discovering which agent actions are hard to judge when you are not staring at the terminal.

Common questions

• What is Cursor agent mode doing when it asks for approval?

  Cursor agent mode is asking you to confirm an action that may affect your workspace or environment, such as running a command or making edits. The useful approval request includes the exact operation and context. If the request is too vague to judge in 10 seconds, tighten your cursor rules before adding remote approval.

• Does PocketVeto replace Cursor rules or code review?

  No. PocketVeto is an approval transport and dashboard, not a policy system or reviewer. Cursor rules still define repository expectations, and code review still catches semantic mistakes. Treat PocketVeto as a way to avoid missed prompts, not as proof that an agent action was safe.

• Can I use PocketVeto with cursor background agents?

  Maybe, but test the exact workflow before relying on it. The repository positions PocketVeto as a local Bluetooth-mediated gate for AI coding agents, with v1 host support on Windows, Linux, and Linux devcontainers. Do not assume it intercepts every Cursor background agents surface unless your host setup proves it.

• Why not just use a web dashboard or VPN?

  Bluetooth is the point because it keeps the approval path local and avoids LAN routing problems such as Wi-Fi AP isolation. A web dashboard may be easier to integrate, but it also expands the network surface. PocketVeto chooses reach-across-the-room over reach-from-anywhere.

• When is this project too much?

  It is too much when you are already at the keyboard, the agent is doing low-risk edits, or the approval prompts are not informative enough to judge remotely. Fix the prompt content first. A remote deny button helps only after the underlying decision is small, specific, and reversible.

Best ways to use this research

• Best for: Cursor users experimenting with longer-running agent work who want a clearer approval boundary without turning every task into a meeting with the terminal.
• Best first artifact: A narrow .mdc rule that forces the agent to show command, directory, affected files, and rollback plan before risky actions.
• Best comparison angle: PocketVeto is most interesting as a local approval surface, not as a general mobile IDE or cloud agent controller.
• Best caution: Do not add remote approval until you can explain which actions are risky and what a safe denial path looks like.

Further reading

• Cursor — Agent
• Cursor — Rules
• pocket-veto — source

Try one narrow approval path

Pick one repo and one risky action, then make the agent ask clearly before it acts. If the approval is easy to understand from your phone, you have found a real boundary; if not, fix the rule before adding more automation.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.