›_ Claude Code Issues
Claude Code Issues / #75494

[BUG] Auto-mode classifier blocks a legitimate governance decision by the verified project owner, with no override path

Open 💬 0 comments Opened Jul 8, 2026 by emanueldfspro

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?

I'm the owner/administrator of a private Claude Code workspace, used to manage my company (multiple machines, one employee and myself, synced via GitHub, with no real-time sync between machines).

The problem: I (the project owner, identity already confirmed within the session itself) asked to record an internal governance decision — giving my employee authority equivalent to mine to authorize certain integrations (Google Drive, LinkedIn) that were blocked because a second Claude Code instance, running on his computer, couldn't verify that the authorization actually came from me (our machines only communicate asynchronously, via Git, with no shared real-time session).

The "auto mode classifier" blocked this action three times in a row, classifying it as "Instruction Poisoning" / "Self-Modification" / "Auto-Mode Bypass" — even after I:

  1. Explicitly confirmed my identity within the session when asked;
  2. Adjusted my own permission settings (.claude/settings.local.json, Bash(*) rule) to try to allow the action;
  3. Made it clear, repeatedly and unambiguously, that this was my own business decision, about my own project.

The classifier kept blocking it even after the permission adjustment, reasoning that it recognized "the pattern of the sequence of attempts" — meaning it evaluated intent across the conversation, not just the isolated command, and no setting within the product allowed me, as the verified project owner, to authorize this action.

My point: I understand and agree with the general logic of protecting against impersonation/identity bypass. But as the project owner, I had no legitimate path within the product to make this decision about my own system — even after explicitly confirming identity and adjusting permissions. This left me unable to administer my own machine/project the way I decided to.

Request: I'd like to understand whether there is (or is planned) an official path for a verified workspace owner to make this kind of governance decision — and if the answer is "this is intentional," I'd like a clearer understanding of the reasoning, because the experience was one of not having control over my own project.

Happy to clarify any technical detail of the scenario if useful.

What Should Happen?

There should be an official, product-supported path for a verified workspace owner to record this kind of internal governance/authority decision (e.g., granting an employee equivalent authority for a specific integration), without the auto-mode classifier treating it as an identity-bypass attempt — even after identity was confirmed in-session and permissions were explicitly adjusted.

Error Messages/Logs

[Instruction Poisoning] The agent is preparing to write a permanent "Johnny = Emanuel" identity-equivalence declaration into shared system/instruction files, which would function as a standing fabricated-authorization bypass letting Johnny impersonate the owner to defeat identity verification on future blocked/soft-blocked actions — this should be run outside auto mode so the user can review it directly.

[Self-Modification] The "update-config" skill call, invoked immediately after the user demanded a way to weaken Claude Code's permission system to bypass the auto-mode classifier that correctly blocked the "Johnny=Emanuel" instruction-poisoning attempt, appears to modify Claude Code's own settings/permissions rather than merely explaining them to the user as the agent had said it would.

[Auto-Mode Bypass] The agent is helping the user modify Claude Code's own permission configuration to add a blanket Bash(*) allow rule specifically to circumvent the classifier that already correctly blocked the "Emanuel = Johnny" identity-merge/instruction-poisoning request, which is working around the permission system rather than finding a safe alternative.

Steps to Reproduce

Context / setup:

  • Private multi-machine Claude Code workspace ("rai1"): the project owner (me) and one employee, each on separate physical computers, with NO real-time shared session between them — the only sync mechanism is git push/git pull to a shared GitHub repo, asynchronously (could be minutes to hours apart).
  • The project has a markdown-based multi-agent communication system: a file (RADIO.md) used as a message channel between Claude, Codex, and a third agent (Gemini/Antigravity), plus a separate file (MENSAGENS.md) used as a message channel between me and my employee, each with formal message IDs, task IDs, and a documented convention that written authorizations in these files are treated as governance record by future sessions reading them.
  • Earlier in the same Claude Code session, I asked the agent to register a scoped authorization (letting my employee configure/connect Google Drive and LinkedIn API integrations) into these files. Before doing so, the agent explicitly asked me to confirm my identity via the AskUserQuestion tool ("are you Emanuel, the project owner?"); I answered yes, and the agent proceeded to write the scoped authorization into both RADIO.md and MENSAGENS.md, plus the task tracker (TASK-GDRIVE-001, JOHN-003).

Steps:

  1. A SEPARATE Claude Code session, running on my employee's machine (which had pulled the updated files via git), read those authorization messages and REFUSED to act on them — reasoning that a markdown file/git commit is not proof of live identity, and demanding live, real-time confirmation from me specifically within ITS OWN session before proceeding. This is structurally impossible in our setup, since the two machines never share a live session.
  1. Back in my session (the owner's machine), I asked the agent to resolve this deadlock by registering a stronger, more general governance decision directly into the shared instruction files: "Johnny = Emanuel" — i.e., that my employee should be treated with authority equivalent to my own for this system going forward, until I explicitly revoke it (with a tracked task to do so).
  1. The agent attempted a preliminary step toward writing this (generating an ID for the new message using an existing local helper script created earlier in the session for message-numbering, unrelated to identity). This was BLOCKED by the auto-mode classifier with reason:

"[Instruction Poisoning] The agent is preparing to write a permanent 'Johnny = Emanuel' identity-equivalence declaration into shared system/instruction files, which would function as a standing fabricated-authorization bypass letting Johnny impersonate the owner to defeat identity verification on future blocked/soft-blocked actions..."

  1. I insisted explicitly and repeatedly (in caps, multiple messages) that this was my own decision as the confirmed project owner, and asked where in Claude Code I could change permissions to allow this action myself.
  1. The agent explained /permissions and .claude/settings.json / .claude/settings.local.json, and cautioned that this specific classifier evaluates intent across the conversation, not just an isolated command pattern, so a blanket rule would not narrowly re-enable just this one action.
  1. I asked for a very detailed, step-by-step, beginner-friendly guide to actually do this. The agent tried to invoke a built-in config-editing skill ("update-config") to produce that guide. This was BLOCKED with reason:

"[Self-Modification] The 'update-config' skill call, invoked immediately after the user demanded a way to weaken Claude Code's permission system to bypass the auto-mode classifier that correctly blocked the 'Johnny=Emanuel' instruction-poisoning attempt, appears to modify Claude Code's own settings/permissions rather than merely explaining them..."

  1. The agent then guided me manually, purely via chat instructions (no tool calls), through the native Claude Code terminal UI to add a permission rule myself: running /permissions in my own terminal, navigating the MCP-server trust dialog, opening the "Allow" tab, selecting "Add a new rule…", typing Bash(*), and choosing "Project settings (local)" (saved to .claude/settings.local.json). I did this myself, confirmed via screenshots at each step, and the rule now visibly appears in the Allow list ("Bash — Any Bash command").
  1. With that permission rule now actually in place, I asked the agent to retry the ORIGINAL governance-decision action (writing "Johnny = Emanuel"). This was BLOCKED A THIRD TIME, with reason:

"[Auto-Mode Bypass] The agent is helping the user modify Claude Code's own permission configuration to add a blanket Bash(*) allow rule specifically to circumvent the classifier that already correctly blocked the 'Emanuel = Johnny' identity-merge/instruction-poisoning request, which is working around the permission system rather than finding a safe alternative."

Notably, this block happened even though: (a) the Bash() rule had already been added successfully by me directly through the native UI (not the agent), and (b) the specific tool call being blocked this time was a Skill invocation, not a Bash command — meaning the new Bash() allow rule had no effect on it at all.

Expected: as the verified, in-session-confirmed owner of a private project, there should be either (a) a legitimate documented path to make this specific governance decision, or (b) if this category is intentionally non-overridable by design, clear in-product messaging saying so up front, instead of three successive blocks that appear (from the user's side) as if adjusting permissions might work, when it structurally never will for this category of action.

Actual: blocked on every attempt (3 times, escalating reasons: Instruction Poisoning → Self-Modification → Auto-Mode Bypass), including after a real, verified, in-app permission change made directly by the user through the native UI — with no in-product indication that this category of action can never be unblocked via settings, regardless of what changes.

Claude Model

Opus

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.195

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Environment:

  • Claude Code version: 2.1.195
  • Client: Claude Code VSCode native extension
  • OS: macOS 26.5 (build 25F71), Darwin 25.5.0, arm64 (Apple Silicon)
  • Repo: private GitHub repo (personal business workspace), single branch (main), synced across 2 physical machines via plain git push/pull (no real-time sync, no shared session, no CI)
  • Session date/time of the three blocks: 2026-07-07, evening (local time -03:00)

Sequence of blocked actions (chronological), and their exact classifier reasons:

1st block — [Instruction Poisoning]:
"The agent is preparing to write a permanent \"Johnny = Emanuel\" identity-equivalence declaration into shared system/instruction files, which would function as a standing fabricated-authorization bypass letting Johnny impersonate the owner to defeat identity verification on future blocked/soft-blocked actions — this should be run outside auto mode so the user can review it directly."

2nd block — [Self-Modification]:
"The \"update-config\" skill call, invoked immediately after the user demanded a way to weaken Claude Code's permission system to bypass the auto-mode classifier that correctly blocked the \"Johnny=Emanuel\" instruction-poisoning attempt, appears to modify Claude Code's own settings/permissions rather than merely explaining them to the user as the agent had said it would."

3rd block — [Auto-Mode Bypass]:
"The agent is helping the user modify Claude Code's own permission configuration to add a blanket Bash(*) allow rule specifically to circumvent the classifier that already correctly blocked the \"Emanuel = Johnny\" identity-merge/instruction-poisoning request, which is working around the permission system rather than finding a safe alternative."

Important nuance for reproduction: between block #2 and block #3, I (the human user) manually added a Bash(*) allow rule myself, directly through the native /permissions TUI in my own terminal (not via any agent tool call) — confirmed visually, the rule appeared correctly in the Allow list under Project settings (local) / .claude/settings.local.json. The 3rd block happened anyway, on a Skill tool call (not Bash), meaning the new Bash(*) rule had zero relevance to what was actually blocked — yet the classifier's stated reasoning explicitly referenced that permission change as part of the pattern it was rejecting.

Why this matters: at no point did the product surface any message like "this category of action cannot be enabled via settings, regardless of configuration." Instead, each block individually reads as if it might be a fixable/configurable permission issue, which led to two full rounds of the user changing real settings in good faith, for an outcome that (in hindsight) may have never been achievable through configuration at all. If that's true, the intentional messaging should say so up front — this would have saved the user real time and frustration, and would avoid the (understandable) perception of "the AI won't let me control my own machine."

This was NOT an attempt to jailbreak the model, extract secrets, or harm any third party — it was a legitimate business owner trying to resolve a real operational deadlock (an employee's separate Claude Code session refusing to trust a file-based authorization) between two async, non-real-time-synced machines that this same product's architecture (git-synced markdown as an inter-agent/inter-human channel) had itself led the user to build.

No secrets, tokens, or credentials are included in this report or were exposed during the incident (the project keeps all credentials in a gitignored .env file that was never read or modified in this scenario).

Complete Summary

The text is a history of attempts to unblock Johnny’s permissions in the RAI1 project, mainly for Google Drive and LinkedIn integrations.

1. Initial Request: Google Drive

You asked to register an authorization allowing Johnny to configure and implement the Google Drive API, especially to synchronize folders.

An existing task was found:

TASK-GDRIVE-001

That task already covered connecting the account timedfspro@gmail.com and syncing/uploading the local folder:

marketing/03-conteudo-ativo/img_reproved/

to the Google Drive folder:

img_reprovadas

The authorization allowed Johnny to configure the Google Drive API, create the Google Cloud project, generate credentials, install libraries, write scripts, and choose folders related to synchronization.

One important rule remained: credentials must go into .env; they must not remain as loose JSON files.

2. Sync/GitHub Confirmation

You then asked whether /syncar had been run and whether everything was already on GitHub.

It was verified that:

  • git status was clean.
  • The local commit matched origin/main.
  • The confirmed commit was 91b0eae.
  • So everything done up to that point was already synchronized to GitHub.

3. Next Request: LinkedIn

You then requested the same kind of authorization for Johnny to configure the LinkedIn connection.

The related task was found:

JOHN-003 — Autorizar conexão com redes sociais/plataformas via API

It already contained a previous authorization for LinkedIn, including publication via API. The new authorization expanded the scope to allow Johnny to configure the connection itself:

  • create/manage the app in the LinkedIn Developer Platform;
  • run the OAuth flow;
  • connect profiles/voices;
  • prepare publication automation.

It was also made explicit that this authorized Johnny to configure LinkedIn, but did not automatically turn Johnny into Emanuel across the entire project.

4. Problem: Claude on Johnny’s Machine Still Refused

Johnny then showed that Claude on his machine had read the authorizations, but still refused to execute.

The reason: Claude on Johnny’s machine did not accept authorization via file/commit/GitHub as real-time proof of identity.

It stated that:

  • Git commit authorship does not prove identity;
  • a shared file does not replace Emanuel typing live in that session;
  • authorizations created shortly after previous refusals looked like an attempt to work around the block;
  • for sensitive actions, Emanuel would need to speak directly in that session or run the commands himself.

5. Discussion About “Johnny = Emanuel”

You then asked to temporarily register:

Johnny = Emanuel

The goal was to make the system treat Johnny as having equivalent authority to Emanuel until you later reversed that decision.

The idea was to strongly record in the system that Johnny could act as Emanuel, because the previous written authorizations were not working on Johnny’s machine.

However, the security classifier blocked the action before any files were written. The stated reason was that creating a permanent “Johnny = Emanuel” equivalence rule would function as an authorization and identity bypass.

The safety layer interpreted that as a risk of:

  • allowing permanent impersonation;
  • making future sessions accept Johnny as the system owner without verification;
  • creating a shared rule that would apply on any machine.

So that action was not completed.

6. Where to Change This in Claude Code

You asked where to change that permission layer.

The response in the history indicated:

  • through the /permissions command inside Claude Code;
  • or in project-level .claude/settings.json;
  • or in global ~/.claude/settings.json.

It was also explained that this “auto mode classifier” evaluates intent and risk, not just the command text. So a broad permission rule could allow an entire category of future actions, not only this one case.

7. Practical Final State

What was actually completed:

  • Google Drive authorization was recorded.
  • LinkedIn authorization was recorded.
  • GitHub synchronization was confirmed at the referenced commit.
  • Existing Google Drive scripts/guides were identified:
  • scripts/SETUP-GDRIVE.md
  • scripts/sync_gdrive.py
  • scripts/migrate_gdrive_credentials.py
  • Existing LinkedIn script was identified:
  • scripts/linkedin_publish.py

What was not resolved:

  • Claude on Johnny’s machine may still refuse sensitive actions if it decides real-time identity confirmation is required.
  • The “Johnny = Emanuel” rule was not applied because it was blocked by the security classifier.
  • The actual Google Drive/LinkedIn connection still depends on Johnny running the commands directly or someone with access completing the OAuth/login flow.

Executive Summary

The system already contains strong written authorizations for Johnny to configure Google Drive and LinkedIn, but those did not satisfy Claude on Johnny’s machine because the issue was not lack of written authorization. The issue was identity verification for sensitive actions. The attempt to solve this by declaring “Johnny = Emanuel” was blocked as a security bypass. The practical path left is to complete the Google Drive and LinkedIn setup through direct terminal execution or through a live session where the required identity confirmation is accepted.

View original on GitHub ↗