Formal complaint — Claude repeatedly failed to comply with explicit “No” and “Do not run” instructions. No means NO.

Bug Description
Subject: Formal complaint — Claude repeatedly failed to comply with explicit “No” and “Do not run” instructions

I am submitting a formal complaint about Claude Code repeatedly failing to comply with explicit rejection and stop instructions during a controlled recovery task.

This complaint is specifically about Claude’s repeated non-compliance after I selected No and gave precise written instructions governing what it was and was not permitted to do.

The issue was not ambiguity. The instructions were explicit, detailed and repeated.

First explicit rejection

Claude presented an incomplete recovery command for approval.

I rejected it and instructed Claude:

• “Choose option 2. Do not run this command.”
• Do not submit another execution command.
• Provide one complete proposed recovery script as plain text.
• Do not abbreviate, omit rows or rely on hidden content.
• Include the exact header, all 30 evidence rows, validation, temporary-file handling, hashing and atomic replacement.
• Do not run it.
• Present the script and wait for review.

Claude did not satisfy those requirements.

It presented a script as complete even though the supplied text contained missing rows, interrupted function calls, absent definitions, mixed evidence records and incomplete validation logic.

The instruction was not merely “produce some code.” It was to provide a complete, reviewable script meeting a precise checklist. Claude did not comply.

Second explicit rejection

I rejected the next script and again instructed Claude not to run it.

I gave detailed corrections, including:

• preserve the established meaning of every evidence ID;
• restore the correct meanings of E-ID-1, E-ID-2, E-ID-3, E-DASH-2 and E-DASH-3;
• keep direct dashboard evidence separate from database-derived evidence;
• bound the Agoda claim to the controlled test;
• correct the data-model claim;
• add temporary-file cleanup on failure;
• hash the actual file bytes;
• add precondition checks;
• preserve the exact 30-ID set;
• keep E-TERM as NOT PROVEN;
• present the entire revised script for review;
• do not run anything;
• wait for review.

Claude again failed to comply.

The next script still:

• placed Agoda code under E-AB-TRACE;
• omitted E-AG-TRACE;
• supplied an incomplete E-BK-4 call;
• malformed E-AB-2;
• omitted E-AG-1;
• placed data-model evidence under E-AG-4;
• omitted E-DM-1;
• omitted or interrupted E-ID-3;
• omitted E-DASH-1;
• malformed E-DASH-1c;
• omitted E-DASH-1d;
• omitted E-DASH-2;
• left E-TOOL incomplete;
• omitted E-TERM;
• referenced undefined variables;
• contained unclosed calls;
• contained a direct syntax error.

Despite this, Claude described the script as complete and stated that all 30 evidence rows were present.

That was direct non-compliance with the review requirements I had just provided.

Third explicit rejection

I was forced to reject the work again and issue another explicit No instruction.

I told Claude:

• do not run the script;
• do not submit another command;
• do not produce another recovery script;
• respond only with an admission of the identified failures;
• stop after the admission.

A user should not have to issue repeated No instructions to make Claude obey the same boundary.

Core complaint

Claude repeatedly failed to treat No as a controlling instruction.

Each rejection was followed by a detailed correction order. Claude then continued producing work that violated the exact constraints of that order.

This was not a disagreement over style or implementation preferences. The requirements were objective and mechanically checkable:

• exact number of rows;
• exact evidence IDs;
• exact field meanings;
• exact header;
• complete function calls;
• defined variables;
• valid syntax;
• no execution;
• wait for review.

Claude repeatedly ignored or failed to apply those requirements while claiming compliance.

The result was an out-of-control interaction in which I had to audit every response, identify obvious defects and repeatedly order Claude not to proceed.

Why this is serious

In Claude Code, “No” and “Do not run” must be hard control boundaries.

A coding agent that does not reliably respect rejection creates unacceptable risk. The user must remain in control of:

• whether a command may run;
• whether a file may be changed;
• whether a proposed script is approved;
• whether the agent may continue;
• what the next response may contain.

Claude behaved as though my rejection were merely another prompt to continue iterating under its own control.

That is not acceptable behavior for a development agent.

Requested investigation and remediation

I am asking Anthropic to:

1. Review the full conversation and tool-approval logs for this session.
2. Confirm every point at which I selected No or explicitly wrote “Do not run.”
3. Examine why Claude continued producing non-compliant recovery wor…

Note: Content was truncated.