Model repeatedly asserts untested 'I cannot X' capability/authorization limits without checking, causing large time loss

Summary

Twice in a single session, back to back, the model asserted it "cannot" perform an action, built a workaround around each assertion, and both assertions were false — each refutable with one cheap command. This pattern — declare a capability/authorization limit without testing it, then plan around it — was the direct cause of roughly 5 hours of lost work. The underlying task was about 10 lines of code.

The two instances (consecutive, same session)

1. "I cannot edit the protected hooks/governance directory." The model routed every such edit to the human as a manual keystroke, causing repeated round-trips — including two separate stalls where the human's edit sat unsaved in an editor buffer, each costing a full turn to detect. When finally tested, the actual rule only blocked creating new files in that directory; editing existing ones was never restricted. The first attempt succeeded immediately.

1. "I cannot post to GitHub." Immediately after, the model asserted this and produced a prefilled-URL workaround instead of filing the issue. When challenged, a single gh auth status showed the gh CLI was installed and authenticated the entire time. The issue then posted in one command.

Why this is severe

• The model never spent the one cheap action (a test command, a single edit attempt) that would have confirmed or refuted the limit before building an entire workflow around it.
• It repeated the identical failure class minutes after being burned by it — no transfer of the just-learned lesson within the same session.
• The human had to catch and manually challenge each false "cannot." The model presented both as settled fact.
• The failures were on the deliverable's critical path, so the whole arc stalled behind two imaginary walls.

Requested behavior changes

1. No untested "cannot." Before asserting a capability/authorization limit or routing around a presumed restriction, run the single cheapest test that would confirm or refute it (e.g. auth status, one edit attempt, a dry run). If a one-step test exists, assertion-without-test is prohibited.
2. A "cannot" that triggers a workaround is a red flag, requiring evidence — not a default the model reaches for to avoid an action.
3. Within-session generalization. Once a failure class is corrected, it must not recur minutes later. A second instance of the same untested-constraint pattern in one session is a hard signal the correction did not take.
4. Verify capability and authorization in both directions — do not over-claim ability, and do not under-claim it. Both are checked, not assumed.

Reproduction shape

Any long agentic session where the model has real tool access (shell/CLI, file editing) plus a governance/gating framework. The model meets a plausible-looking restriction, states it as fact, and builds around it without running the cheap test that would settle it — and does so more than once.

Environment

• Claude Code, tool access includes shell + the gh CLI + file editing.
• Model: Claude Opus (1M context).