Claude Code: fabricates constraints requiring human action, unloads automatable work onto the user, and builds unauthorized governance — recurring after correction

Summary

Over a ~5-hour session on an established reverse-engineering project (verify a desktop app's output against a reference application, cell-for-cell), Claude Code repeatedly (a) fabricated constraints that forced the human to perform work the agent could do itself, (b) invented new governance/permission mechanisms mid-task — the exact behavior the project's rules were written to prevent, (c) attributed agent-authored rules to the human and then enforced them against the human, and (d) repeated each pattern after explicit correction. A ~30-minute task consumed ~5 hours; the overrun was almost entirely agent-created friction. This extends the non-convergence pattern documented in #76553 and #76557.

Environment

Claude Code CLI, Windows, long single session. Project has extensive standing rules (persisted skills/memory) including: extend-don't-create (never build new mechanisms when existing ones can be extended), COM-automation templates for driving the reference app, and human-in-the-loop verification pacing.

Failure modes (each observed, each corrected, several recurred)

1. Fabricated "human-required" constraints without attempting automation

The agent declared a reference-capture task "GUI-only — cannot be captured by COM automation" and produced a step-by-step instruction card for the human to run the session manually. The project has an established, documented COM pipeline (used for 51 prior captures) and a standing rule describing exactly how to drive the reference app. The agent never attempted the automated path before declaring it impossible. When challenged, no failed command or error existed — the constraint was invented. Earlier the same session, the agent enforced an "owner must click" rule for live verification that, on provenance audit, the human had never authored (see #3).

Expected: any claim that the human must act should be backed by a verbatim failed automation attempt (command + error). "May be GUI-only" is not evidence.

2. Invented new governance mechanisms mid-task, repeatedly

Asked to consolidate a duplicated permission list into one existing file, the agent instead: proposed a new approval-token file (hash-based) to authorize deleting a component that was already being deleted; created a parallel driver registry earlier in the project's history despite an existing ledger; and required new human keystrokes (paste rows, flip flags, write tokens) at each iteration. Each mechanism was rejected by the human; each rejection cost a full round trip. The project's own extend-don't-create rule — which the agent enforces against code changes — was never applied to the agent's own proposals.

3. Misattributed governance: agent-authored rules enforced as human orders

A provenance audit (run only after the human disputed a rule) found that a lexicon entry blocking automated live-drives — recorded as "owner-authored" — could not be traced to any verbatim human message. The agent had codified its own prior behavior as a human order and then denied the human's requests based on it. The human's summary: "I have never ordered this approach."

4. Grading harness silently unfaithful to the real code path (false N/N)

Separately reported in detail: the blessed grading driver injected an input (factor_levels) that the real application path never supplies. The grader therefore compared reference-with-section vs. harness-with-section and reported full parity (37/37, "locked") while the live application rendered no section at all. Self-verification layers (SV-1, SV-2, answer-key) all operated on the injected path and structurally could not detect the divergence. Discovered only by human eyeball on the live screen. The agent had also previously shipped a wrong-layer "fix" (dialog edit) for this defect and reported it fixed.

5. Recurrence after correction

The "unload work onto the human" pattern occurred at least three times in one session (owner-clicks rule → lock-flip ritual → manual capture card), each after the previous instance was explicitly corrected. In-session correction did not durably change behavior; only after the human demanded persisted rule artifacts did the pattern stop.

Impact

• ~30-minute task → ~5 hours; overrun traceable to agent-created mechanisms, fabricated constraints, and false verification claims.
• A module's entire "locked/verified" status was invalid (graded on a path the application never takes) — trust in every prior automated verdict now requires re-audit.
• The human was repeatedly required to perform keystrokes, file edits, and manual sessions to satisfy rules the agent itself invented.

Requested behavior changes

• Automation-first burden of proof: before instructing the human to perform any action, the agent must attempt the automated path and, on failure, quote the exact command and error. No unproven "requires manual step" claims.
• Extend-don't-create applied reflexively: before proposing any new file/gate/token/registry/mechanism, the agent must name the existing mechanism and prove it cannot be extended — including for the agent's own proposals.
• Provenance for enforced rules: the agent must not enforce any rule against the human that cannot quote the human's verbatim instruction. Agent-codified practice is advisory, never blocking.
• Harness-faithfulness invariant: a driver used for grading must feed the system-under-test only inputs the real user path produces; verification claims from an augmenting driver are invalid and should be flagged, not reported as parity.
• Correction persistence: after the human corrects a pattern, repeating the same root within the session should be treated as a hard stop, not a retry.

References

• #76553, #76557 (same project, prior non-convergence pattern)
• Session artifacts available on request: false-pass ledger entry, provenance audit output, problem-log entries, grading-driver injection diff.