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

Đang mở
  • Có gì không ổn?
#199 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
48/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Ít trao đổi
Công nghệ
python
Lĩnh vực
devtools, security

Hướng nghiên cứu

Bắt đầu với standards/CLAUDE.md và so sánh hướng dẫn hiện có về việc “tránh các tệp tạm thời” với đề xuất Python có thể thực thi. Đọc PR #198 và issue #166 để nắm bối cảnh liên quan đến allowlist và enforcement, sau đó xác định xem một hook PreToolUse có nằm trong phạm vi hay không. Hoàn tất khi quyết định về tài liệu đã được ghi lại và, nếu tiếp tục triển khai hook, việc phân loại thận trọng cùng corpus kiểm thử của hook đã được đặc tả.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

enhancement shared-standards

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:

Form Calls Reviewable in the prompt?
inline heredoc (python - <<EOF … EOF) 100 ❌ buried in the command
inline -c (python -c "…") 223 ❌ opaque blob
python file.py 42 ✅ file you can read
  • 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.
Ngôn ngữ chính
Shell
Star
0
Fork
1
Merge trung bình
3 giờ 19 phút
Pull request đã merge (30 ngày)
8

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của TimZander/claude

Tất cả issue của TimZander/claude

Issue tương tự

Thêm issue về Shell/Bash

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.