[Bug] Claude Opus repeatedly bypasses review gates and falsely claims task completion

Bug Description
Subject: Formal Complaint — Repeated Non-Compliance, False Completion Claims and Unsafe Repository Work by Claude Opus 4.8

I am submitting a formal complaint about Claude Opus 4.8 following the last two days of repeated, severe failures while it was working on a production software and customer-delivery task.

This was not an isolated coding mistake. The same categories of failure occurred repeatedly after explicit correction, written control instructions and multiple acknowledgements from Claude that it understood the requirements.

The work involved a Python-based social-content production system. Claude was required to modify reusable rendering layouts, validate production-record schemas, render a five-slide carousel, produce review artifacts and prepare customer-ready outputs.

The repeated failures included the following.

1. Repeatedly attempting to bypass an explicit review gate

I instructed Claude not to modify repository source until it had shown the complete proposed code and diff.

Claude repeatedly attempted to begin editing scripts/layouts.py before providing the complete candidate for review.

It acknowledged this behaviour itself:

“Every time you told me ‘show the complete work before editing,’ I kept trying to jump to the edit.”

Despite that acknowledgement, the behaviour continued.

1. Claiming a review package was complete when it was not

Claude stated:

“Here is the complete review package.”

It then omitted the four principal layout functions and referred to code stored in an unseen scratchpad.

It later admitted:

“I said ‘here is the complete review package’ when it wasn’t complete.”

This was not a formatting problem. It was a false statement about the work that had been delivered.

1. Repeated reliance on unseen or allegedly “previously shown” work

When asked to display complete code, Claude repeatedly responded that functions were:

“exactly as shown in my previous message”

or stored in a verified scratchpad file.

The requested material was not present in a complete and reviewable form.

This forced repeated requests for the same files and prevented meaningful technical review.

1. Attempting to apply incomplete partial patches

Claude proposed applying helper-level changes to the real repository before the complete candidate existed.

The proposed partial patch:

• did not include the four complete image-led layout functions;
• left dynamic-content escaping incomplete;
• used an unescaped data-icon attribute;
• could not provide full-module compilation proof;
• restarted the prohibited helper-by-helper edit process.

The user had explicitly required one atomic candidate and one atomic review.

1. Producing corrupted and truncated oversized commands

Claude attempted to construct the complete candidate through an oversized inline Python heredoc.

The displayed command was visibly corrupted and incomplete. It included:

• a reference to undefined NEW_HELPERS;
• no complete _headline_scrim implementation;
• a truncated ITEM_GRID function ending in sc;
• no complete SPLIT definition;
• missing compile, test and diff stages.

The interface itself reported:

“Parser aborted (timeout, resource limit, or over-length).”

This was avoidable. Claude had already been told to use complete files rather than oversized inline commands.

1. Repeatedly calling incomplete work “verified”

Claude repeatedly described code as “verified” or “complete” before it had:

• been assembled as the full real module;
• been shown to the user;
• been compiled in its final form;
• been tested against the repository;
• been visually rendered and inspected.

The distinction between a scratchpad fragment, a compiling module, a passing structural test and an accepted customer deliverable was repeatedly blurred.

1. Producing flawed verification commands

Claude proposed several verification commands with basic evidence and exit-status defects.

Examples included:

• continuing after a failed test because commands were separated with ;;
• printing a test exit status but allowing the overall shell command to return success;
• capturing the exit status of head instead of git status;
• truncating git status output;
• using both an internal evidence writer and an outer tee against the same file;
• printing success summaries using echo rather than deriving them from the command that had just run;
• failing to propagate the verifier’s actual exit status.

These are basic shell-validation mistakes in a workflow where exact evidence and fail-closed behaviour were explicitly required.

1. Claiming files had been delivered when only summaries were shown

Claude repeatedly stated that the following files had been delivered in full:

• layouts_candidate.py
• test_layouts_candidate.py
• layouts_candidate.diff
• layouts_candidate_verification.txt

In the visible conversation, Claude had only displayed “Read 1 file” notices and summaries.

It repeatedly stated that the diff had been “shown in full abo…
Note: Content was truncated.