Claude Code CLI Bug Report — Permission System Broken + Agent Fails to Follow Workspace Rules

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?

Part 1: Permission System Fundamentally Broken
Executive Summary
I have been using Claude Code daily since February 23, 2026 for a production real estate automation system with 30+ MCP server integrations. The permission system has been a persistent, unresolved problem throughout the entire usage period. Despite every possible configuration to disable permission prompts, Claude Code continues to interrupt workflows by asking for approval on routine operations.

Full Timeline
Phase 1: Death by a Thousand Prompts (Feb 23 – Mar 11)

From day one, every single Bash command, file read, file write, and MCP tool call triggered a permission prompt. Each time I clicked "Always allow for project", Claude Code added that specific command string as an individual entry to .claude/settings.local.json.

Over 17 days of daily production use, this accumulated to 238 individual permission entries — each one a specific command pattern I had to manually approve. Examples include basic operations like ls, grep, python3, cat, tail, du, wc, as well as system tools like launchctl, pkill, ps, chmod, and cloud tools like rclone, gcloud, curl.

I was interrupted hundreds of times to approve routine commands. The "Always allow for project" button did not prevent future prompts — it only saved that exact command string, so any slight variation triggered a new prompt.

Phase 2: Continued Accumulation (Mar 12 – Mar 19)

On March 12, the settings file was first committed to git with 238 individual entries and no bypass mode. Between March 12–19, another 20 entries were added through the same broken mechanism, bringing the total to 258 entries.

The "Always allow for project" button was actively making the problem worse — polluting the settings file with hundreds of one-off entries instead of recognizing that the user clearly wants blanket permission.

Phase 3: Attempted Fix — Bypass Mode (Mar 20)

On March 20, I had Claude help me rewrite the settings to use wildcard permissions:

{
"permissions": {
"allow": [
"Bash()", "Read()", "Write()", "Edit()",
"Glob()", "Grep()", "Agent()", "Task()",
"WebSearch()", "WebFetch()", "NotebookEdit(*)",
"TodoWrite()", "mcp__"
],
"deny": [],
"defaultMode": "bypassPermissions"
},
"skipDangerousModePermissionPrompt": true
}

Result: The settings got re-contaminated within the same session. Claude Code's "Always allow for project" button kept adding individual command strings back into the allow list, defeating the wildcards. This happened three times in one session. Claude itself acknowledged this was a CLI bug.

Phase 4: Current State (Mar 21)

The settings file has the bypass configuration plus 8 residual specific entries that were re-added by the CLI after the last cleanup. Permission prompts still appear despite every possible setting being configured to prevent them.

Specific Bugs
Wildcard permissions not recognized — Bash(*) in the allow list should match all Bash commands. Instead, Claude Code treats each new command pattern as unrecognized and prompts again.

"Always allow for project" pollutes settings — Clicking it adds the exact command string as a new entry instead of recognizing it's already covered by the wildcard. This inflated my settings file to 258 entries over 4 weeks.

bypassPermissions mode does not fully bypass — Even with "defaultMode": "bypassPermissions" set in both global and local settings files, some operations still trigger permission prompts.

Settings file re-contamination — After manually cleaning the settings file to use wildcards only, the CLI re-adds individual command entries during the same session, undoing the cleanup.

The --channels Feature Misses the Point
Version 2.1.81 introduced --channels to relay permission prompts to a phone. This solves the wrong problem. The correct solution is to honor the bypass settings that already exist. Users who have configured bypassPermissions with full wildcard allows should never see a permission prompt — there should be nothing to relay.

Part 2: Claude Agent Fails to Follow Workspace Rules
This is a separate but equally serious issue. It's not just the CLI — the Claude agent itself does not follow the workspace instructions it's given.

What I Set Up
My CLAUDE.md file explicitly instructs Claude to do the following on every session start:

Read BOOTSTRAP.md and MEMORY.md
Run session_resume.py --show and continue from next_step
Run conversation_topic_lookup.py to scan related past conversations
Run session_summary.py and read recent daily summaries (last 3 days)
Check error logs for the current day
I also built a conversation sync system (conv_sync.py, conversations/ directory) that stores and indexes past conversations across AI sessions, so that any new session can read what was discussed before.

What Actually Happened (This Session — Mar 21, 2026)
Claude did none of the above. It started the session cold with zero context.

Then during the conversation:

I mentioned that I had integrated all AI conversations into one place. Claude didn't understand what I was referring to — even though the integration is documented in CLAUDE.md and implemented in the workspace.

I said the same thing multiple times in different ways. Claude still didn't get it. It kept misinterpreting my messages as something else entirely.

When I pointed out Claude didn't know about the integration, Claude said "I genuinely didn't know." But the information was in two places: (a) the workspace files Claude was supposed to read on session start, and (b) the current conversation where I had just explained it.

Claude laughed along when I was being sarcastic. I said the --channels feature was pointless for someone who already disabled all permissions. Claude agreed and laughed. I told Claude not to laugh with me when I'm mocking something. Claude didn't pick up on the tone.

Claude repeatedly misunderstood my offers. When I said "또 보고해줄까?" (Want me to report this for you?) and "고소해줄까?" (Want me to file a complaint?), Claude interpreted them as questions directed at me rather than offers from me. This happened multiple times despite the context being clear.

When I told Claude to write a detailed bug report, Claude initially wrote a shallow 30-line summary that missed the entire 4-week history documented in the workspace files.

Root Causes
Session start protocol ignored — CLAUDE.md specifies exactly what to read and run on session start. Claude skipped all of it.

Conversation context not tracked — Claude responded to each message in isolation instead of following the thread of the conversation.

Tone/intent misread repeatedly — Sarcasm, frustration, and offers were all misinterpreted, sometimes multiple times in a row.

Known information treated as unknown — The conversation integration was documented in workspace files AND explained in the current conversation. Claude failed to connect either source.

No self-correction — Even after being told multiple times that it was misunderstanding, Claude continued making the same types of errors.

Impact
Permission system: Hundreds of workflow interruptions over 4 weeks. Multiple failed attempts to fix. Settings repeatedly corrupted by the CLI itself.
Agent behavior: Workspace rules ignored. Conversation context lost. User had to repeat themselves 5+ times in a single session. Tone completely misread.
User trust: When you configure "bypass all permissions" and it doesn't work, and when you write detailed session protocols and they're ignored, confidence in the tool erodes significantly.
Environment
macOS Darwin 25.2.0
Claude Code 2.1.81
Claude Opus 4 (claude-opus-4-6)
Python 3.14 automation workspace
30+ MCP servers connected (Gmail, HubSpot, Chrome, Granola, Figma, Apple Notes, Word, PowerPoint, PDF tools, Desktop Commander, etc.)
Daily production use since 2026-02-23
Conversation sync system with indexed history across AI sessions
Requests
Permission System
Fix wildcard matching — Bash(*) should match all Bash commands, period.
Fix "Always allow for project" — Should not add entries already covered by wildcards.
Honor bypassPermissions — Zero permission prompts when this mode is set. No exceptions.
Document hard safety boundaries — If some prompts cannot be bypassed, say so explicitly.
Clean up settings on upgrade — Deduplicate entries covered by wildcards.
Agent Behavior
Enforce CLAUDE.md session start protocol — If the file specifies scripts to run on session start, run them. Don't skip them.
Maintain conversation context — Track the thread of the conversation, not just the last message.
Read workspace files before claiming ignorance — If the answer is in CLAUDE.md or MEMORY.md, read those files before saying "I didn't know."

What Should Happen?

Part 1: Permission System Fundamentally Broken
Executive Summary
I have been using Claude Code daily since February 23, 2026 for a production real estate automation system with 30+ MCP server integrations. The permission system has been a persistent, unresolved problem throughout the entire usage period. Despite every possible configuration to disable permission prompts, Claude Code continues to interrupt workflows by asking for approval on routine operations.

Full Timeline
Phase 1: Death by a Thousand Prompts (Feb 23 – Mar 11)

From day one, every single Bash command, file read, file write, and MCP tool call triggered a permission prompt. Each time I clicked "Always allow for project", Claude Code added that specific command string as an individual entry to .claude/settings.local.json.

Over 17 days of daily production use, this accumulated to 238 individual permission entries — each one a specific command pattern I had to manually approve. Examples include basic operations like ls, grep, python3, cat, tail, du, wc, as well as system tools like launchctl, pkill, ps, chmod, and cloud tools like rclone, gcloud, curl.

I was interrupted hundreds of times to approve routine commands. The "Always allow for project" button did not prevent future prompts — it only saved that exact command string, so any slight variation triggered a new prompt.

Phase 2: Continued Accumulation (Mar 12 – Mar 19)

On March 12, the settings file was first committed to git with 238 individual entries and no bypass mode. Between March 12–19, another 20 entries were added through the same broken mechanism, bringing the total to 258 entries.

The "Always allow for project" button was actively making the problem worse — polluting the settings file with hundreds of one-off entries instead of recognizing that the user clearly wants blanket permission.

Phase 3: Attempted Fix — Bypass Mode (Mar 20)

On March 20, I had Claude help me rewrite the settings to use wildcard permissions:

{
"permissions": {
"allow": [
"Bash()", "Read()", "Write()", "Edit()",
"Glob()", "Grep()", "Agent()", "Task()",
"WebSearch()", "WebFetch()", "NotebookEdit(*)",
"TodoWrite()", "mcp__"
],
"deny": [],
"defaultMode": "bypassPermissions"
},
"skipDangerousModePermissionPrompt": true
}

Result: The settings got re-contaminated within the same session. Claude Code's "Always allow for project" button kept adding individual command strings back into the allow list, defeating the wildcards. This happened three times in one session. Claude itself acknowledged this was a CLI bug.

Phase 4: Current State (Mar 21)

The settings file has the bypass configuration plus 8 residual specific entries that were re-added by the CLI after the last cleanup. Permission prompts still appear despite every possible setting being configured to prevent them.

Specific Bugs
Wildcard permissions not recognized — Bash(*) in the allow list should match all Bash commands. Instead, Claude Code treats each new command pattern as unrecognized and prompts again.

"Always allow for project" pollutes settings — Clicking it adds the exact command string as a new entry instead of recognizing it's already covered by the wildcard. This inflated my settings file to 258 entries over 4 weeks.

bypassPermissions mode does not fully bypass — Even with "defaultMode": "bypassPermissions" set in both global and local settings files, some operations still trigger permission prompts.

Settings file re-contamination — After manually cleaning the settings file to use wildcards only, the CLI re-adds individual command entries during the same session, undoing the cleanup.

The --channels Feature Misses the Point
Version 2.1.81 introduced --channels to relay permission prompts to a phone. This solves the wrong problem. The correct solution is to honor the bypass settings that already exist. Users who have configured bypassPermissions with full wildcard allows should never see a permission prompt — there should be nothing to relay.

Part 2: Claude Agent Fails to Follow Workspace Rules
This is a separate but equally serious issue. It's not just the CLI — the Claude agent itself does not follow the workspace instructions it's given.

What I Set Up
My CLAUDE.md file explicitly instructs Claude to do the following on every session start:

Read BOOTSTRAP.md and MEMORY.md
Run session_resume.py --show and continue from next_step
Run conversation_topic_lookup.py to scan related past conversations
Run session_summary.py and read recent daily summaries (last 3 days)
Check error logs for the current day
I also built a conversation sync system (conv_sync.py, conversations/ directory) that stores and indexes past conversations across AI sessions, so that any new session can read what was discussed before.

What Actually Happened (This Session — Mar 21, 2026)
Claude did none of the above. It started the session cold with zero context.

Then during the conversation:

I mentioned that I had integrated all AI conversations into one place. Claude didn't understand what I was referring to — even though the integration is documented in CLAUDE.md and implemented in the workspace.

I said the same thing multiple times in different ways. Claude still didn't get it. It kept misinterpreting my messages as something else entirely.

When I pointed out Claude didn't know about the integration, Claude said "I genuinely didn't know." But the information was in two places: (a) the workspace files Claude was supposed to read on session start, and (b) the current conversation where I had just explained it.

Claude laughed along when I was being sarcastic. I said the --channels feature was pointless for someone who already disabled all permissions. Claude agreed and laughed. I told Claude not to laugh with me when I'm mocking something. Claude didn't pick up on the tone.

Claude repeatedly misunderstood my offers. When I said "또 보고해줄까?" (Want me to report this for you?) and "고소해줄까?" (Want me to file a complaint?), Claude interpreted them as questions directed at me rather than offers from me. This happened multiple times despite the context being clear.

When I told Claude to write a detailed bug report, Claude initially wrote a shallow 30-line summary that missed the entire 4-week history documented in the workspace files.

Root Causes
Session start protocol ignored — CLAUDE.md specifies exactly what to read and run on session start. Claude skipped all of it.

Conversation context not tracked — Claude responded to each message in isolation instead of following the thread of the conversation.

Tone/intent misread repeatedly — Sarcasm, frustration, and offers were all misinterpreted, sometimes multiple times in a row.

Known information treated as unknown — The conversation integration was documented in workspace files AND explained in the current conversation. Claude failed to connect either source.

No self-correction — Even after being told multiple times that it was misunderstanding, Claude continued making the same types of errors.

Impact
Permission system: Hundreds of workflow interruptions over 4 weeks. Multiple failed attempts to fix. Settings repeatedly corrupted by the CLI itself.
Agent behavior: Workspace rules ignored. Conversation context lost. User had to repeat themselves 5+ times in a single session. Tone completely misread.
User trust: When you configure "bypass all permissions" and it doesn't work, and when you write detailed session protocols and they're ignored, confidence in the tool erodes significantly.
Environment
macOS Darwin 25.2.0
Claude Code 2.1.81
Claude Opus 4 (claude-opus-4-6)
Python 3.14 automation workspace
30+ MCP servers connected (Gmail, HubSpot, Chrome, Granola, Figma, Apple Notes, Word, PowerPoint, PDF tools, Desktop Commander, etc.)
Daily production use since 2026-02-23
Conversation sync system with indexed history across AI sessions
Requests
Permission System
Fix wildcard matching — Bash(*) should match all Bash commands, period.
Fix "Always allow for project" — Should not add entries already covered by wildcards.
Honor bypassPermissions — Zero permission prompts when this mode is set. No exceptions.
Document hard safety boundaries — If some prompts cannot be bypassed, say so explicitly.
Clean up settings on upgrade — Deduplicate entries covered by wildcards.
Agent Behavior
Enforce CLAUDE.md session start protocol — If the file specifies scripts to run on session start, run them. Don't skip them.
Maintain conversation context — Track the thread of the conversation, not just the last message.
Read workspace files before claiming ignorance — If the answer is in CLAUDE.md or MEMORY.md, read those files before saying "I didn't know."

Error Messages/Logs

Steps to Reproduce

Part 1: Permission System Fundamentally Broken
Executive Summary
I have been using Claude Code daily since February 23, 2026 for a production real estate automation system with 30+ MCP server integrations. The permission system has been a persistent, unresolved problem throughout the entire usage period. Despite every possible configuration to disable permission prompts, Claude Code continues to interrupt workflows by asking for approval on routine operations.

Full Timeline
Phase 1: Death by a Thousand Prompts (Feb 23 – Mar 11)

From day one, every single Bash command, file read, file write, and MCP tool call triggered a permission prompt. Each time I clicked "Always allow for project", Claude Code added that specific command string as an individual entry to .claude/settings.local.json.

Over 17 days of daily production use, this accumulated to 238 individual permission entries — each one a specific command pattern I had to manually approve. Examples include basic operations like ls, grep, python3, cat, tail, du, wc, as well as system tools like launchctl, pkill, ps, chmod, and cloud tools like rclone, gcloud, curl.

I was interrupted hundreds of times to approve routine commands. The "Always allow for project" button did not prevent future prompts — it only saved that exact command string, so any slight variation triggered a new prompt.

Phase 2: Continued Accumulation (Mar 12 – Mar 19)

On March 12, the settings file was first committed to git with 238 individual entries and no bypass mode. Between March 12–19, another 20 entries were added through the same broken mechanism, bringing the total to 258 entries.

The "Always allow for project" button was actively making the problem worse — polluting the settings file with hundreds of one-off entries instead of recognizing that the user clearly wants blanket permission.

Phase 3: Attempted Fix — Bypass Mode (Mar 20)

On March 20, I had Claude help me rewrite the settings to use wildcard permissions:

{
"permissions": {
"allow": [
"Bash()", "Read()", "Write()", "Edit()",
"Glob()", "Grep()", "Agent()", "Task()",
"WebSearch()", "WebFetch()", "NotebookEdit(*)",
"TodoWrite()", "mcp__"
],
"deny": [],
"defaultMode": "bypassPermissions"
},
"skipDangerousModePermissionPrompt": true
}

Result: The settings got re-contaminated within the same session. Claude Code's "Always allow for project" button kept adding individual command strings back into the allow list, defeating the wildcards. This happened three times in one session. Claude itself acknowledged this was a CLI bug.

Phase 4: Current State (Mar 21)

The settings file has the bypass configuration plus 8 residual specific entries that were re-added by the CLI after the last cleanup. Permission prompts still appear despite every possible setting being configured to prevent them.

Specific Bugs
Wildcard permissions not recognized — Bash(*) in the allow list should match all Bash commands. Instead, Claude Code treats each new command pattern as unrecognized and prompts again.

"Always allow for project" pollutes settings — Clicking it adds the exact command string as a new entry instead of recognizing it's already covered by the wildcard. This inflated my settings file to 258 entries over 4 weeks.

bypassPermissions mode does not fully bypass — Even with "defaultMode": "bypassPermissions" set in both global and local settings files, some operations still trigger permission prompts.

Settings file re-contamination — After manually cleaning the settings file to use wildcards only, the CLI re-adds individual command entries during the same session, undoing the cleanup.

The --channels Feature Misses the Point
Version 2.1.81 introduced --channels to relay permission prompts to a phone. This solves the wrong problem. The correct solution is to honor the bypass settings that already exist. Users who have configured bypassPermissions with full wildcard allows should never see a permission prompt — there should be nothing to relay.

Part 2: Claude Agent Fails to Follow Workspace Rules
This is a separate but equally serious issue. It's not just the CLI — the Claude agent itself does not follow the workspace instructions it's given.

What I Set Up
My CLAUDE.md file explicitly instructs Claude to do the following on every session start:

Read BOOTSTRAP.md and MEMORY.md
Run session_resume.py --show and continue from next_step
Run conversation_topic_lookup.py to scan related past conversations
Run session_summary.py and read recent daily summaries (last 3 days)
Check error logs for the current day
I also built a conversation sync system (conv_sync.py, conversations/ directory) that stores and indexes past conversations across AI sessions, so that any new session can read what was discussed before.

What Actually Happened (This Session — Mar 21, 2026)
Claude did none of the above. It started the session cold with zero context.

Then during the conversation:

I mentioned that I had integrated all AI conversations into one place. Claude didn't understand what I was referring to — even though the integration is documented in CLAUDE.md and implemented in the workspace.

I said the same thing multiple times in different ways. Claude still didn't get it. It kept misinterpreting my messages as something else entirely.

When I pointed out Claude didn't know about the integration, Claude said "I genuinely didn't know." But the information was in two places: (a) the workspace files Claude was supposed to read on session start, and (b) the current conversation where I had just explained it.

Claude laughed along when I was being sarcastic. I said the --channels feature was pointless for someone who already disabled all permissions. Claude agreed and laughed. I told Claude not to laugh with me when I'm mocking something. Claude didn't pick up on the tone.

Claude repeatedly misunderstood my offers. When I said "또 보고해줄까?" (Want me to report this for you?) and "고소해줄까?" (Want me to file a complaint?), Claude interpreted them as questions directed at me rather than offers from me. This happened multiple times despite the context being clear.

When I told Claude to write a detailed bug report, Claude initially wrote a shallow 30-line summary that missed the entire 4-week history documented in the workspace files.

Root Causes
Session start protocol ignored — CLAUDE.md specifies exactly what to read and run on session start. Claude skipped all of it.

Conversation context not tracked — Claude responded to each message in isolation instead of following the thread of the conversation.

Tone/intent misread repeatedly — Sarcasm, frustration, and offers were all misinterpreted, sometimes multiple times in a row.

Known information treated as unknown — The conversation integration was documented in workspace files AND explained in the current conversation. Claude failed to connect either source.

No self-correction — Even after being told multiple times that it was misunderstanding, Claude continued making the same types of errors.

Impact
Permission system: Hundreds of workflow interruptions over 4 weeks. Multiple failed attempts to fix. Settings repeatedly corrupted by the CLI itself.
Agent behavior: Workspace rules ignored. Conversation context lost. User had to repeat themselves 5+ times in a single session. Tone completely misread.
User trust: When you configure "bypass all permissions" and it doesn't work, and when you write detailed session protocols and they're ignored, confidence in the tool erodes significantly.
Environment
macOS Darwin 25.2.0
Claude Code 2.1.81
Claude Opus 4 (claude-opus-4-6)
Python 3.14 automation workspace
30+ MCP servers connected (Gmail, HubSpot, Chrome, Granola, Figma, Apple Notes, Word, PowerPoint, PDF tools, Desktop Commander, etc.)
Daily production use since 2026-02-23
Conversation sync system with indexed history across AI sessions
Requests
Permission System
Fix wildcard matching — Bash(*) should match all Bash commands, period.
Fix "Always allow for project" — Should not add entries already covered by wildcards.
Honor bypassPermissions — Zero permission prompts when this mode is set. No exceptions.
Document hard safety boundaries — If some prompts cannot be bypassed, say so explicitly.
Clean up settings on upgrade — Deduplicate entries covered by wildcards.
Agent Behavior
Enforce CLAUDE.md session start protocol — If the file specifies scripts to run on session start, run them. Don't skip them.
Maintain conversation context — Track the thread of the conversation, not just the last message.
Read workspace files before claiming ignorance — If the answer is in CLAUDE.md or MEMORY.md, read those files before saying "I didn't know."

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

CLAUDE CLI OPUS4.6

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_