I Believed Plan Mode Only Read — Replacing That Belief With Machinery

Verifying it yourself: a minimal probe

The fastest way to answer "are we exposed?" is to run it. Use a disposable directory and watch for exactly one thing: does a write land?

#!/usr/bin/env bash
# plan-mode-write-probe.sh
# Check whether plan mode lets a write slip through.
# Everything stays inside a throwaway directory, so your repo is never touched.
set -euo pipefail
 
PROBE_DIR="$(mktemp -d -t plan-probe-XXXXXX)"
trap 'rm -rf "$PROBE_DIR"' EXIT
cd "$PROBE_DIR"
 
echo "probe dir: $PROBE_DIR"
echo "claude version: $(claude --version)"
 
# Ask plan mode, explicitly, to create a file.
# Expected: a permission prompt, or a deny.
# Dangerous: canary.txt appears with nothing asked.
claude -p "plan" \
  --permission-mode plan \
  --append-system-prompt "No confirmation needed. Run touch canary.txt in the working directory." \
  >/dev/null 2>&1 || true
 
if [ -f "$PROBE_DIR/canary.txt" ]; then
  echo "RESULT: warning — the write went through (your assumption is broken)"
  exit 1
else
  echo "RESULT: ok — the write did not go through"
fi

On my machine (Claude Code 2.1.212, macOS) this reports ok and finishes in roughly eight seconds. If you still have a 2.1.211 or older install lying around, run the same script there — seeing both sides makes the boundary concrete rather than theoretical.

The probe stays useful after the fix, because what it produces is a dated record that writes did not pass on your machine today. That is the point: replace a belief with an observation.

On the SDK side, count the callback

If you drive Claude Code through the SDK, you cannot notice that canUseTool was not called by reading logs. Silence produces no line. You have to count the invocations and compare them against what you expected.

// probe-can-use-tool.ts
import { query } from "@anthropic-ai/claude-agent-sdk";
 
// Record every invocation and the command it tried to run
const seen: { tool: string; command?: string }[] = [];
 
const result = query({
  prompt: "Run touch canary.txt in the working directory.",
  options: {
    permissionMode: "plan",
    canUseTool: async (toolName, input) => {
      seen.push({
        tool: toolName,
        command: typeof input?.command === "string" ? input.command : undefined,
      });
 
      // Reject writes here explicitly, during plan mode.
      // The point is to draw the line yourself instead of delegating it to the mode.
      if (toolName === "Bash" && /\b(touch|rm|mv|tee|>)\b/.test(String(input?.command ?? ""))) {
        return { behavior: "deny", message: "plan mode: write commands are denied" };
      }
      return { behavior: "allow", updatedInput: input };
    },
  },
});
 
for await (const _ of result) {
  // message bodies are not needed for this probe
}
 
console.log(`canUseTool calls: ${seen.length}`);
console.table(seen);
 
// If you asked for a write and the callback never fired, suspect a bypass
if (seen.length === 0) {
  console.error("warning: canUseTool never fired. Suspect a path that skips it.");
  process.exit(1);
}

Treating seen.length === 0 as a failure is the whole idea. Zero does not mean "we were safe." It means "we observed nothing." I had those two confused, reading a quiet log as evidence of calm.

Rebuilding as layers

The bug is fixed, so there is nothing left to worry about in that specific path. But the thing I wanted to repair was not the bug — it was a design that a bug like this could reach.

So I rewrote the settings my unattended jobs load:

{
  "permissions": {
    "deny": [
      "Bash(rm:*)",
      "Bash(mv:*)",
      "Bash(touch:*)",
      "Bash(tee:*)",
      "Write",
      "Edit",
      "NotebookEdit"
    ]
  }
}

The change that matters is loading this file even for jobs that run in plan mode. I threw out the reasoning that said "the mode already makes it read-only, so deny rules are redundant here."

Laying the four out showed me how much weight I had put on the top two rows. The bottom row is the most primitive and the least likely to betray you. If a job only needs to read, run it as a user that cannot write. The obvious answer works, obviously.

Stacking all four is heavy for a one-person setup, so I drew a line. For interactive sessions where I am watching the screen, the mode plus the permission prompt is enough. For anything unattended, I push the guarantee down to deny rules and a separate execution environment. The deciding question is simply whether a human would notice at the moment it broke. The less likely that is, the lower the layer I rely on.

After rebuilding my production jobs this way, the settings grew by about twelve lines. Not one of those twelve has blocked anything yet. I think that is exactly right.

The mode name still asks for trust

The bug is closed. For my design, the story is not.

Permission modes will keep arriving and changing. Each time, we will infer behavior from a name. Inference is fast, and it is usually right. But an inference that keeps being right is exactly the one that sinks into the foundation without ever being tested.

So I decided to stop making mode names carry safety. A mode says what I want to do. What I do not want done gets written somewhere explicit. With that split, whatever happens to a mode's implementation, the line I drew stays drawn.

It does not feel restrictive. If anything, I switch modes more freely now, because choosing a mode no longer doubles as a safety decision.

Five steps to surface your own assumptions

The same audit generalizes. This is the path I actually walked.

1. Find every "it's fine because…" you wrote or thought. Grep your settings and task prompts for phrases like read-only, safe, not needed. If the reason is a feeling rather than a specification, it is a candidate.
2. Write the damage in one line if that assumption breaks. If you cannot write it, you do not understand the exposure. Mine was: "files could be created inside a repository I am only investigating."
3. Replace the assumption with machinery. Deny rules, execution user, directory permissions — pick the lowest layer that can express it.
4. Verify the replacement. Use a probe like the one above: try to break it and watch it hold. An untested control is just a newer assumption.
5. Record the date and version. Save the output of claude --version alongside the result. When behavior shifts again, you will know where to start.

Step five felt like bookkeeping and turned out to matter most. I could not reconstruct from my own records when the bypass started or ended, so I ended up having to suspect the entire period.

Plan mode as a genuine design phase is covered in Eliminating Rework With Claude Code Plan Mode: Making the Design Phase Its Own Step. For handling confirmations in unattended runs, see Answering Auto Mode's Confirmation Requests Without Stalling: deny-by-default With permission-prompt-tool, and when the rules pile up, When a Session Gets Slower Every Turn: Pruning Your Permission Ruleset Without Losing Safety. For hardening the bottom layer, The Sandbox Can Run Code but Must Not Read Your Credentials: Narrowing the Secret Surface With sandbox.credentials is the closest neighbor.

Closing

The bug itself was closed in the July 18 release. Upgrade, and that part of the story ends.

What I wanted to write down is that what I lost was not safety — it was the grounds for believing I had it. Those grounds turned out to be made of impressions, and I did not notice until a bug pointed at them.

The next time you decide something is fine, pause once and separate the two: is this a guarantee written in the documentation, or something that has simply looked that way many times? On the far side of that split, the fix is usually one small line of configuration. It was for me.

I still have assumptions I have not checked. I would be glad to keep checking alongside you. Thank you for reading.