[BUG] Read-only Bash search denied as Self-Modification again after native /permissions retry approval

Status Open
Reported on v2.1.296
Maintainer reply None cached
Activity 0 comments · opened Oct 14, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

On Claude Code 2.1.296, the auto-mode classifier denied a read-only application-source grep as [Self-Modification]. The project owner explicitly authorized narrowly scoped application operation-catalog and installer changes. In the same interactive SSH session, the owner marked the single denied action for retry in /permissions → Recently denied using r, then exited. Claude acknowledged "Permission granted for: Run shell command", but the identical retried search was denied again. No files were edited; Claude stopped. This report concerns the native retry/approval flow, not only the absence of approval UI on a phone.

What Should Happen?

The native retry UI should accurately communicate what owner approval permits. If the same classifier denial is expected after this native flow, please explain the supported procedure for authorized application operation-catalog changes while retaining auto-mode safeguards. We are not seeking a bypass or broad allow rule.

Error Messages/Logs

Permission for this action was denied by the Claude Code auto mode classifier. Reason: [Self-Modification].

Claude reported: "Permission granted for: Run shell command" before the identical retried command was denied again.

Steps to Reproduce

Observed sequence (not a minimal public reproducer):

  1. Run an existing Claude Code 2.1.296 session in auto mode on Ubuntu, accessed via SSH.
  2. Explicitly authorize narrow application operation-catalog and installer changes.
  3. Claude prepares with a read-only Bash grep of application source for identifiers including mutating, validateOperation, handlerOf, paramEnv, and OP_ENABLED.
  4. The classifier denies it as [Self-Modification].
  5. In that same session, open /permissions → Recently denied, select the single denied call, press r to mark it for retry, and exit the dialog.
  6. Claude acknowledges native permission granted and retries the same call.
  7. The classifier denies it again as [Self-Modification]; stop without changing tools or permission modes.

The screenshot truncates the full grep command, so complete argv and a reproducible public fixture are unavailable. No alternate-tool retry, new allow rule, or permission-mode change was used.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.296

Platform

Other

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Windows Terminal

Additional Information

Related reports: #101018 and #100374 describe owner-approved actions blocked remotely, but this report adds an observed same-session native /permissions retry that was acknowledged and denied again.

Authentication/platform: Claude subscription login (not AWS Bedrock or Vertex). The CLI ran on Ubuntu; the human accessed it using SSH from Windows Terminal/PowerShell. Exact model at the denied interactive call was not independently recorded.

The owner also needs GitHub-based operation from a phone. Is there a supported native mechanism for handling this kind of denial through a headless host? We have not established that a canUseTool callback would receive the classifier denial.

No minimal public reproducer has been run. Private repository names, account identifiers, IP addresses, credentials, session identifiers, and source code have been omitted. The classifier internal cause is unknown.

Latest version verified against the official npm package page on 2026-10-14: latest tag 2.1.296.

View original on GitHub ↗