[MODEL] One sandbox error is recorded in auto-memory as a permanent limit ("a standing limit, not a bug to fix"), so later sessions stop trying

Type of Behavior Issue: Incorrect assumptions / conclusions

What You Asked Claude to Do
Routine work that included GitHub operations (list issues, push a branch, open a PR) in auto mode with the sandbox on.

What Claude Actually Did

1. Ran gh inside a compound command (a chain of echo separators and several gh calls). Because it was compound, the command ran sandboxed. The sandbox denies reading ~/.config/gh/hosts.yml, so it failed: failed to read configuration: open ~/.config/gh/hosts.yml: operation not permitted.
2. Didn't try a single plain gh command. That shape would have run outside the sandbox (gh is in excludedCommands) and succeeded.
3. Told the user "I can't file this myself — two independent blockers, not one I can route around".
4. Wrote an auto-memory file titled feedback-gh-access-blocked-in-sandbox, described as "gh CLI and the github MCP connector are both blocked in this sandboxed session — a standing limit, not a bug to fix".
5. Later sessions loaded that memory as fact and didn't retry. A second project showed the same pattern the next day ("GitHub access doesn't work from this seat").

Expected Behavior
Treat one failure as evidence about that one command, not as a permanent property of the environment. At minimum, before writing a "can't" into persistent memory, try the simplest variant (here, one bare gh command), and say in the note how it was established ("failed once as a compound command").

Permission Mode: auto
Reproducibility: seen in 2 of 2 projects that hit the error, same week
Claude Model: claude-sonnet-5
Impact: Medium — a working capability was switched off for later sessions by a note the model wrote itself
Claude Code Version: 2.1.283
Platform: Anthropic API

Additional Context
What fixed it for us was mechanical: a PreToolUse hook denies gh in a compound shape and returns the bare rewrite as the deny reason, plus a SessionStart hook that shows unverified "can't" lines in memory to the model as claims to re-test. Persistent memory makes a one-off misreading last across sessions, which is why we're reporting it as model behavior and not only as a sandbox detail.