Throwaway python scripts prompt constantly but are unreviewable — make them safe/auditable

Problem

Agents frequently write throwaway python for analysis (parsing transcripts/logs, counting, JSON munging). Each invocation triggers a Bash permission prompt, but the script is usually an inline blob — so the prompt is unreadable in practice and gets rubber-stamped. That defeats the point of the prompt: it provides friction without safety.

Evidence (scan of local transcripts)

415 Bash calls invoke python. Breakdown:

• 77% (323) are inline. They are not one-liners: 269 are 6–40+ lines (132 at 6–15, 112 at 16–40, 25 at 40+).
• A 20–40 line python blob in a permission prompt cannot be validated at a glance, so approval is reflexive.

Why the allowlist approach does NOT apply

Unlike read-only git/gh/az reads (allowlisted in #198), python can do anything — write files, delete, network. So python:* can't be allowlisted. The prompt is correctly firing; the problem is that it is unreviewable, so it degrades into a rubber-stamp.

Proposed approaches

1. Standard: executable python is reviewable-by-construction (cheap)

Add to standards/CLAUDE.md, with a boundary against the existing "avoid temp files" rule:

• The existing rule governs text passed to a CLI (gh --body) → heredoc is fine.
• Executable code is different. Any python beyond a true one-liner should be written to a named scratchpad file (via the Write tool, which renders it as readable content) with a one-line docstring stating read-only intent, then run as python file.py. The logic becomes reviewable as a file; the Bash command becomes trivial.

2. Hook: make the prompt meaningful (higher value, the real fix)

A PreToolUse hook that statically classifies the python before it runs:

• No write/network/delete indicators (open(...,'w'/'a'), subprocess, os.system, os.remove/unlink/rename, shutil, socket, requests/urllib/http) → pure analysis → auto-approve, no prompt.
• Any indicator present → prompt as normal, ideally surfacing the flagged lines.

This applies the #198 philosophy to python: don't prompt for provably read-only work; focus human attention only on scripts that touch the world. Converts ~77% opaque rubber-stamps into either silent-safe or a focused prompt. The classifier must be conservative — auto-approve only when clearly side-effect-free; prompt on any doubt — to avoid false negatives.

3. Prefer core tools where they suffice

Some of these scripts do what Grep/Glob already do without a prompt. Reinforce "core tools first" (complex JSON/transcript analysis genuinely needs python, so this only partially helps).

Acceptance criteria

• standards/CLAUDE.md states: executable python beyond a one-liner goes to a named scratchpad file (readable via Write) + python file.py, not an inline heredoc; with the text-vs-code boundary against the "avoid temp files" rule made explicit.
• Decision recorded on whether to build the read-only-python PreToolUse hook.
• If pursued: hook classifies inline/file python as read-only vs side-effecting; auto-approves only the conservatively-safe set; ships with a test corpus (known read-only and known-mutating scripts) proving no false negatives.

Related

• PR #198 — read-only allowlist (same "don't prompt for provably-safe operations" philosophy; python is the case an allowlist can't cover).
• #166 — standards/context hygiene theme; the hook is the deterministic enforcement tier discussed there.

Start with standards/CLAUDE.md and compare its existing “avoid temp files” guidance with the executable-Python proposal. Read PR #198 and issue #166 for the related allowlist and enforcement context, then determine whether a PreToolUse hook is in scope. Done means the documentation decision is recorded and, if the hook proceeds, its conservative classification and test corpus are specified.