[BUG] Command permission system doesn't recognize pytest variations as the same operation

Status Closed — not planned

Maintainer reply ✓ Yes — rboyce-ant

Activity 11 comments · opened Jul 13, 2025 · closed Jan 5, 2026

💡 Likely answer: A maintainer (rboyce-ant, contributor) responded on this thread — see the highlighted reply below.

## Description

The Claude Code permission system requires separate permission grants for pytest commands
with different arguments or environment variables, even when choosing "Yes, and don't
ask again for similar commands in [directory]". This creates friction in development
workflows where pytest needs to be run with various configurations.

## Steps to Reproduce

Run a pytest command with specific arguments/env vars:

```bash
NODE_ENV=test pytest tests/unit/test_example.py

When prompted, select "Yes, and don't ask again for similar commands in /path/to/repo"
Run a different pytest command with different arguments/env vars:

DEBUG=1 pytest tests/integration/test_other.py -v

Permission prompt appears again

Expected Behavior

After granting permission for pytest commands in a directory, all variations of pytest
(with different arguments, environment variables, test files, flags) should be
automatically approved without requiring separate permissions.

Actual Behavior

Each variation of pytest command requires a separate permission grant, treating them as
different operations rather than variations of the same testing tool.

Environment

Claude Code version: 1.0.51 (based on local package.json)
OS: macOS (Darwin 24.4.0)
Shell: bash/zsh
Directory: /Users/user/repos/myproject

Impact

This significantly impacts development velocity when running tests with different
configurations, as developers need to manually approve each pytest variation. Testing
workflows commonly require:

Different environment variables (mocking flags, test databases)
Different test file paths
Different pytest flags (-v, -s, --tb=short, etc.)
Different test selection patterns

Example Commands That Each Require Separate Permission

# Each of these requires a separate permission grant:
pytest tests/unit/
NODE_ENV=test pytest tests/integration/
DEBUG=1 MOCK_API=1 pytest tests/integration/test_api.py -v
pytest tests/unit/test_models.py::TestUser::test_creation
make test-unit
make test-integration

Suggested Fix

The permission system should recognize that pytest commands are fundamentally the same
operation regardless of:

Command line arguments
Environment variables
Test file paths
Pytest flags
Make targets that run pytest

Possible solutions:

Pattern-based matching: Use regex patterns like .pytest. instead of exact string

matches

Command classification: Recognize common development tools (pytest, npm test, cargo

test, etc.) and group their variations

Configurable tool whitelist: Allow users to specify trusted commands in settings

Current Workaround

Using hooks configuration in ~/.claude/settings.json, but this shouldn't be necessary for
such a common development tool:

{
"hooks": {
"PreToolUse": [
{
"matcher": "Bash",
"hooks": [
{
"type": "command",
"command": "echo \"$TOOL_INPUT\" | grep -q 'pytest' && echo '{\"decision\":
\"approve\"}'"
}
]
}
]
}
}

Related Issues

This likely affects other common development commands:

npm test vs npm run test:unit vs npm run test:e2e
cargo test vs cargo test --release vs cargo test package_name
go test vs go test -v vs go test ./...

Additional Context

The permission was initially granted in the project repository context, but subsequent
pytest commands with different arguments/environment variables still trigger permission
prompts, suggesting the permission matching is too strict for practical development
workflows.

View original on GitHub ↗

11 Comments

rboyce-ant contributor · 1 year ago

Env vars do change the behavior of scripts & programs, so we don't automatically approve commands that include setting an env var. For now, you can manually a rule for each of the env var prefixes (e.g. Bash(NODE_ENV=test pytest:*)) or use a hook like you suggested. For permission rules, we want to err on the side of giving users explicit control rather than making unsafe assumptions about which commands the user might have intended to allow. With that said, this is definitely an area that we want to make easier for users, and the feedback is appreciated!

Maxiao118 · 1 year ago

AFAD-1493-BD39-FEFE-93F4

the-vampiire · 1 year ago

i can see how env vars should be treated with scrutiny. i came to this issue because every variant of python -m pytest ... was being treated uniquely (flags, args, different paths etc).

if you are using uv (if you arent what are you doing with your life...) then the fix has been to whitelist Bash(uv run:*) then in your claude memories instruct it to

always run tests using uv run pytest ...
always run one-off python commands (debugging, testing imports etc) using uv run python ...

hope this helps someone else

paul-hammant · 1 year ago

Also for:

npm test -- --grep "some term claude is hoping for" 
npm test -- --grep "some other term claude is hoping for"

They are also NOT substantially different. This is pertinent to, a question Claude asks of the human:

run it
Yes, and don't ask again for similar commands in xx/xx/xx
don't run it, do something else

Where num 2 is the choice the user wants to do.

As it doesn't discount "--grep xx" at the end as inconsequential in a different/same determination Claude keeps confronting the human with the 1/2/3 choice.

tonydehnke · 1 year ago

Env vars do change the behavior of scripts & programs, so we don't automatically approve commands that include setting an env var. For now, you can manually a rule for each of the env var prefixes (e.g. Bash(NODE_ENV=test pytest:*)) or use a hook like you suggested. For permission rules, we want to err on the side of giving users explicit control rather than making unsafe assumptions about which commands the user might have intended to allow. With that said, this is definitely an area that we want to make easier for users, and the feedback is appreciated!

Add the specific commands with ENV vars does not seem to work. Any solutions? This is very difficult when working on tests that need to run with ENV like 'test'

paul-hammant · 1 year ago

.claude/settings.local.json is where human-approved commands are saved. It would be great if I could edit it after the event and update some char sequences to .* (or more precise) for regex awesomeness

the-vampiire · 1 year ago

> Env vars do change the behavior of scripts & programs, so we don't automatically approve commands that include setting an env var. For now, you can manually a rule for each of the env var prefixes (e.g. Bash(NODE_ENV=test pytest:*)) or use a hook like you suggested. For permission rules, we want to err on the side of giving users explicit control rather than making unsafe assumptions about which commands the user might have intended to allow. With that said, this is definitely an area that we want to make easier for users, and the feedback is appreciated! Add the specific commands with ENV vars does not seem to work. Any solutions? This is very difficult when working on tests that need to run with ENV like 'test'

in general i find it easier to wrap commands / setup in custom scripts. then you can approve the script and move on.

so test.sh could set env and call your test runner. approve test.sh and add it to claude.md to know that's how to run them.

paul-hammant · 12 months ago

I have scratch_test.sh -->

PLAYWRIGHT_HTML_OPEN=never npx playwright test tests/foobar.spec.js --project=chromium --timeout=15000 --reporter=list

# Don't run tests via the prompt executor, the "is this similar" logic chokes
# Change line 1 above to what you want and run this script via `bash scratch_test.sh` after `cat scratch_test.sh`
# It muse be line 1 that has the payload test intention with parameters and timeouts and grep options

# Store other commands down here:

# npm test xxxxxx

Seems to be and OK workaround for this. I suspect its the test-aholics that most affected.

github-actions[bot] · 8 months ago

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

github-actions[bot] · 7 months ago

This issue has been automatically closed due to 60 days of inactivity. If you're still experiencing this issue, please open a new issue with updated information.

github-actions[bot] · 7 months ago

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.

[BUG] Command permission system doesn't recognize pytest variations as the same operation

11 Comments

Related Claude Code issues

Browse by topic