claude-code - 💡(How to fix) Fix [DOCS] Permission mode docs do not define the safe env-var allowlist for Bash auto-approval [1 participants]

Documentation Type

Unclear/confusing documentation

Documentation Location

https://code.claude.com/docs/en/permission-modes

Section/Topic

acceptEdits mode auto-approval rules for Bash commands with environment-variable prefixes

Current Documentation

The docs currently say:

acceptEdits mode lets Claude create and edit files in your working directory without prompting.

In addition to file edits, acceptEdits mode auto-approves common filesystem Bash commands: mkdir, touch, rm, rmdir, mv, cp, and sed. These commands are also auto-approved when prefixed with safe environment variables such as LANG=C or NO_COLOR=1, or process wrappers such as timeout, nice, or nohup. Like file edits, auto-approval applies only to paths inside your working directory or additionalDirectories. Paths outside that scope, writes to protected paths, and all other Bash commands still prompt.

What's Wrong or Missing?

A. The safe-env-var boundary is not defined

The page gives examples of "safe environment variables" but never says whether that set is fixed, which variable names are treated as safe, or that bare assignments to other environment variables should still require a permission prompt.

B. That missing boundary makes permission behavior hard to predict

Readers can reasonably infer from "such as LANG=C or NO_COLOR=1" that other NAME=value <filesystem command> prefixes may also be auto-approved. For security-sensitive permission behavior, the docs should state the rule explicitly instead of leaving it implicit.

Suggested Improvement

Update the acceptEdits section to make the rule explicit.

Before:

These commands are also auto-approved when prefixed with safe environment variables such as LANG=C or NO_COLOR=1...

After:

These commands are auto-approved only when the prefix uses Claude Code's built-in safe environment-variable allowlist (for example LANG, TZ, and NO_COLOR). Bare assignments to other environment variables still require a permission prompt.

If the allowlist is intentionally implementation-defined, add a short note that only a small built-in allowlist is exempt and that arbitrary env-var prefixes are not.

Impact

Medium - Makes feature difficult to understand

Additional Context

Affected Pages:

Total scope: 2 pages affected

Version context: Clarify this permission boundary for v2.1.145 behavior and later so users can predict when Bash commands with env-var prefixes should still prompt.