Answering auto mode's confirmation prompts in headless runs — a deny-by-default permission-prompt-tool

Implementation: a deny-by-default approver as an MCP server

The core policy is to start from deny. Only what the allowlist names gets through; everything else is refused with a reason. Permission accidents come from the "I accidentally allowed it" side, so tipping the default toward deny keeps you on the safe side. This is the same spirit as narrowing the MCP tools you hand an unattended agent.

Start with a small MCP server that holds exactly one tool: the approver. Use the official Node SDK and make it a stdio server that talks over standard input and output.

// approver.mjs — a stdio MCP server that rules on permission, deny-by-default
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";
import { appendFileSync } from "node:fs";
 
const LEDGER = process.env.APPROVAL_LEDGER ?? "/var/log/claude/approvals.jsonl";
 
// Policy: for each tool name, a function that inspects the input and decides
const POLICY = {
  // Read-only tools pass unconditionally
  Read: () => ({ ok: true }),
  Grep: () => ({ ok: true }),
  Glob: () => ({ ok: true }),
  // Writes are allowed only under the designated build directory
  Write: (input) => within(input?.file_path, "/srv/build/"),
  Edit: (input) => within(input?.file_path, "/srv/build/"),
  // Bash: prefix-match an allowlist. rm / curl are denied by default
  Bash: (input) => bashAllow(input?.command ?? ""),
};
 
const BASH_ALLOW = ["git ", "node ", "npm run ", "python3 ", "ls ", "cat "];
 
function within(p, root) {
  if (typeof p !== "string" || !p.startsWith(root) || p.includes(".."))
    return { ok: false, why: `path is outside the work dir: ${p}` };
  return { ok: true };
}
 
function bashAllow(cmd) {
  if (/\brm\s|\bcurl\s|\bsudo\s|>\s*\/etc/.test(cmd))
    return { ok: false, why: `contains a dangerous command: ${cmd.slice(0, 60)}` };
  if (BASH_ALLOW.some((p) => cmd.startsWith(p))) return { ok: true };
  return { ok: false, why: `command not on the allowlist: ${cmd.slice(0, 60)}` };
}
 
function record(entry) {
  try {
    appendFileSync(LEDGER, JSON.stringify({ ts: new Date().toISOString(), ...entry }) + "\n");
  } catch {
    // A ledger write failure must not stop the decision itself
  }
}
 
const server = new McpServer({ name: "unattended-approver", version: "1.0.0" });
 
server.tool(
  "approve",
  "Rule on permission for unattended runs, deny-by-default",
  { tool_name: z.string(), input: z.record(z.any()).optional() },
  async ({ tool_name, input }) => {
    const rule = POLICY[tool_name];
    const verdict = rule ? rule(input ?? {}) : { ok: false, why: `unregistered tool: ${tool_name}` };
 
    const decision = verdict.ok
      ? { behavior: "allow", updatedInput: input ?? {} }
      : { behavior: "deny", message: verdict.why };
 
    record({ tool_name, allowed: verdict.ok, reason: verdict.why ?? "policy match", input });
 
    // The permission-prompt-tool contract: return the JSON as text
    return { content: [{ type: "text", text: JSON.stringify(decision) }] };
  }
);
 
await server.connect(new StdioServerTransport());

Three things matter here. First, the default is deny, so a tool absent from POLICY stops with a reason. Second, every decision is appended to the ledger via record(), so later you can trace "why did it stop." Third, if the ledger write fails, the decision still proceeds — throwing there would let the audit trail take down the actual work it was meant to observe.

Judge the allowlist in two stages: tool name plus input condition

Deciding on the tool name alone is too coarse. Pass Bash wholesale and rm -rf rides along; pass Write wholesale and a config-file overwrite rides along. So the code above judges in two stages: the tool name first, then the contents of its input.

For Bash, it prefix-matches an allowlist while pre-rejecting anything containing rm, curl, sudo, or an append to /etc. For Write or Edit, it checks whether the target sits under the work directory and that there is no .. escape to a parent. Lifting the criterion from "name" to "name plus condition" is enough to draw the line between what you want through and what you want stopped at a realistic place.

Static allowedTools or settings.json can do coarse control too (I covered that in tuning Claude Code's tool permissions). The value of permission-prompt-tool is that it decides at runtime by looking inside the input — and leaves that decision as a record.

The wrapper: split exit codes off the stream-json result

With the approver in place, write the unattended job itself. Register the approver with --mcp-config, point --permission-prompt-tool at its approve tool, take output as stream-json, and judge success from the final result event.

#!/usr/bin/env bash
# nightly.sh — run headless through the approver; split notifications off result
set -euo pipefail
 
export APPROVAL_LEDGER="/var/log/claude/approvals.jsonl"
CONFIG='{"mcpServers":{"approver":{"command":"node","args":["/opt/claude/approver.mjs"]}}}'
OUT="$(mktemp)"
 
claude -p "Regenerate the build artifacts under content/ and commit them" \
  --output-format stream-json --verbose \
  --mcp-config "$CONFIG" \
  --permission-prompt-tool "mcp__approver__approve" \
  > "$OUT" || true
 
# Pull out only the final result event and evaluate it
RESULT="$(grep '"type":"result"' "$OUT" | tail -1)"
IS_ERROR="$(printf '%s' "$RESULT" | node -e 'let s="";process.stdin.on("data",d=>s+=d).on("end",()=>{try{console.log(JSON.parse(s).is_error?1:0)}catch{console.log(1)}})')"
DENIED="$(grep -c '"allowed":false' "$APPROVAL_LEDGER" || true)"
 
if [ "$IS_ERROR" = "1" ]; then
  notify "run failed: result is_error"     # swap in your own notifier (Slack/email/etc.)
  exit 1
elif [ "${DENIED:-0}" -gt 0 ]; then
  notify "run finished but ${DENIED} action(s) were denied — check the ledger"
  exit 2                                    # "done but needs a look" gets its own code
fi
echo "clean run"

What matters is that the exit code splits three ways. 0 is a clean finish, 1 is a failure of the run itself, and 2 is "finished, but a denial occurred" — a needs-attention state. When an auto mode confirmation surfaces as a denial, folding it into success means you'll glance at a "green" log the next morning and never notice that half the cleanup didn't actually run. Giving the gray state its own color is what pays off in unattended operation.

Before / After: from leaning on the dialog to handling it by design

I used to push unattended jobs through with the equivalent of "allow everything." It certainly doesn't stall. But not stalling and being safe are different things. At the moment an emptied variable turns into a wide-reaching delete, there was not a single net to catch it.

Both "never stall." The difference is that After has a receiver — denial and a record. Being able to keep running while tipped toward the safe side is the state I've come to prefer.

Gotchas: precedence, updatedInput, and version drift

A few places that actually cost me time. First, precedence. If a static allow such as allowedTools takes effect first, the question may never reach the permission-prompt-tool. For tools you want the approver to judge, make sure the static layer doesn't already clear them.

Second, updatedInput. Forget to return that field on an allow and the executed input can come back empty or diverge from intent. The safe default is to return the input you received unchanged, swapping it only when you mean to rewrite it.

Third, version drift. Flag names and return shapes get smoothed over as Claude Code updates. When adopting this, have the approver write the received tool_name and input straight to the ledger once, see with your own eyes what questions actually arrive, and only then put it into real operation.

A small first step

You don't need to write the full policy for every tool at once. Run the approver in an observe-only mode for one night — allow everything, but write tool_name and input to the ledger. Read that ledger the next morning and you'll see which tools your unattended job actually calls, and with what inputs. From there, move the safe ones into allow one at a time, and you can ease toward deny-by-default without strain.

I started from that observe mode myself: the first night left over 200 rulings in the ledger, with about 30 unexpected Bash calls mixed in — more than I had assumed. Designing what stops begins with making things visible. I hope this helps in your own runs — thank you for reading.