Local approval queue for AI agents

What exactly did I approve?

Working local prototype. One human reviewer per instance. Public implementation on GitHub.

BigBoss reviews the actions a coding agent submits through an adapter. Structured read-only actions can proceed. File changes and shell commands generally wait in a local browser queue for your decision, and selected command patterns are blocked. Each decision is tied to a hash of the exact action, workspace and policy version.

When several coding agents are working, a request for permission needs context: which project, which action, and which decision will let the work continue? I built BigBoss to put those requests in one local queue and retain the decisions afterward.

I directed the team (the AI coding agents I direct) to build the dashboard, policy routing, SQLite approval store and adapters that connect coding tools to the workflow. It is built with Python’s standard library, Server-Sent Events, and a static web interface.

The question behind it is practical: how can a person keep useful control as the amount of agent work grows?

BigBoss is a supporting control tool for the Consumption Engine. Its approval workflow can be evaluated separately; integration with the engine remains to be demonstrated. This case study describes source revision 5615b72, inspected September 23, 2026.

From proposed action to recorded decision

1. Receive a proposal

   An adapter submits the proposed action with its workspace, run, and a summary for the reviewer.

2. Route it through policy

   BigBoss classifies the request as automatically allowed, pending review, or blocked. Structured read-only actions can proceed; file changes and shell commands generally enter review, while selected command patterns are blocked.

3. Let the person decide

   The dashboard presents the request. The reviewer can approve, reject, or request changes with an instruction.

4. Retain the decision

   SQLite stores requests, decisions, and events. An adapter receives the outcome and must match execution to the action that was approved.

Read the classification policy and approval store.

Approval belongs to a specific proposal

A general “yes” is ambiguous if an agent changes its command afterward. BigBoss stores an action_hash derived from the proposed action, workspace, and policy version. The adapter contract requires execution to match that returned hash.

This makes the approved proposal identifiable. Enforcement still depends on an integrated adapter honoring the contract. A recorded approval does not establish that the action ran or that the agent completed its task successfully.

Keeping state in SQLite also means the decision history is separate from a terminal session. The store tests express expected behavior for request creation, decisions, and retained events.

What the approval controls cover

BigBoss records submitted proposals and decisions. An integration that enforces approval waits for a decision before allowing an action that requires approval.

Implemented record

• The request carries an action_hash of the proposal, workspace, and policy version. Its decision records the enrolled device.
• Request, decision, and enrollment events persist in SQLite. This is a decision history, not a tamper-evident ledger.
• The local Model Context Protocol (MCP) interface exposes no approve or reject tool; decisions remain with the paired reviewer devices.

Integration and host limits

• Current source restricts JSON pairing-code access and requires browser-navigation headers for the pairing page.
• A local process that can spoof those headers, read the admin token, or share the operator's OS user can still enroll. The workflow does not provide host isolation.
• Keeping the coding agent isolated from the approval API (separate OS user, sandbox, or host) is the operator’s duty, not something the workflow provides by itself.

Read the security model, the version at this source revision and the integration notes.

The adapter is part of the design

The public implementation includes an HTTP interface, a local MCP interface, a hook adapter, and a Codex app-server bridge. They connect different kinds of agent events to the same approval store.

The distinction between a status update and an approval request matters. The documented Codex approval path uses its app-server protocol; the repository notes that project hooks do not provide that approval path under codex exec. An integration needs to participate at the point where the harness is waiting for a decision.

Inspect the bridge or follow the repository’s adapter documentation for setup instructions and limitations.

Run the approval flow locally

The quickstart starts the local dashboard and submits a demonstration request. The sample proposes uv sync but does not execute it. It lets a reviewer inspect the request card and decision flow without connecting a live agent.

The current scope is one human reviewer per running instance. It binds locally by default; phone access is opt-in on the local network and requires the web app to remain open for alerts. No hosted BigBoss service is offered.

Run the checks yourself

Release v0.1.0 (399 tests) passed with no skips in four jobs: Ubuntu and Windows, Python 3.12 and 3.13, with no vendor API keys configured. The tagged CI run records that historical result at 10acc53. GitHub may require sign-in to view its logs.

The later source revision described here has a successful CI run. These are my tests on hosted runners, not independent reproduction. Run the suite from a fixed version or inspect the evidence overview.