Permission prompts

Coding agents are built around an explicit consent model. Every tool call that touches your filesystem, runs a shell command, or hits the network can (and often should) surface a permission prompt. Vibetight preserves that boundary, and routes it to the right human, with the right context, no matter which device the agent is running on.

What everyone else ships

Most agent runners give you a settings.json in your home directory and a few buttons in your IDE: approve this prompt, approve every prompt for this session, turn auto-approve on, hope for the best. That works when it’s one developer at one machine. It breaks the moment “the team” is the unit of work.

Two specific gaps every solo-developer tool has:

• There’s no org-level voice. No way for a security officer to say “no agent in this organisation may ever push to main.” Each developer’s rules live on their own laptop.
• The prompt fires where the agent runs. If an agent runs at 2am on a shared headless box, the prompt sits there unanswered until somebody happens to look at that machine.

Vibetight is built for the team case from the start.

What Vibetight does instead

When an agent hits a permission decision mid-task, the task moves into the Action Required lane on your board. Click it and you see the exact tool call the agent is asking to make, with the full input the model produced. Approve or deny with one click. The agent is notified within milliseconds and continues (or backs off gracefully).

A few properties that come for free because we built it this way:

• Cross-device routing. The prompt arrives in your team’s web UI, not on the device the agent happens to be running on. The agent can be running on a colleague’s headless worker; you still see the prompt and answer it from your phone.
• Identity-aware audit. Every decision is recorded against the human who clicked it (or against the policy that auto-approved). See the audit trail for the full surface.
• Smart defaults that keep agents productive. Read-only operations inside the working directory don’t surface a prompt. Things that change state, escape the working directory, or talk to the network do. The shape of “what’s safe” is the part we keep internal: documenting the recipe in detail would tell adversaries exactly what slips past the defaults.

What you’ll never see us ship

• A blanket “approve everything” flag. We don’t expose it. Not even for power users.
• A way to pre-approve “every shell command”. Too broad to be safe.

Allow rules exist (and they’re useful), but they’re always scoped: a specific tool, a specific argument shape, a specific task or project. We talk about the scopes available and the audit semantics on the permissions deep-dive page.

Where this is going

Permission prompts at the individual level are now table stakes; every credible agent runner ships them. The work we’re investing in is the fleet-scale version: org-wide policy, time-window rules (“no production deploys outside business hours”), per-agent personas with their own boundaries, and audit logs designed for security teams rather than individual developers. See the permissions deep-dive for what’s there today and what’s coming.

See also

• Permissions deep-dive: the scopes, the audit trail, and the fleet-governance roadmap
• Audit trail: how decisions are recorded and read back