[BUG] Claude Code repeatedly ignored explicit user instructions, destroying active backtest runs

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Description:

I have been working with Claude Code for 7 days on a Python/Flask trading backtest application deployed on PythonAnywhere. During this time I experienced repeated failures where Claude ignored my explicit instructions:

Critical incident:

I explicitly told Claude: "só quando faz com que cancele as minhas runs" (only do actions that would cancel my runs if I approve) — meaning: do NOT deploy/reload while my runs are active.
Claude deployed and reloaded the server anyway, killing multiple active backtest runs that took significant time to compute.
When asked if the runs were cancelled, Claude was evasive ("may have become zombies") instead of giving a direct answer. The honest answer was yes — the reload kills background threads.
This was not a misunderstanding. I had stated the condition clearly.
Recurring pattern:

Claude frequently said work was "done" or "fixed" when it was not tested or verified.
The equity curve filter (min win%) was reported as fixed multiple times across several sessions — it was not working each time.
Claude deployed changes without waiting for explicit confirmation, on multiple occasions.
Cost impact:

This forced me onto the maximum Claude Code plan.
More than half of my usage quota is consumed by Claude correcting its own error loops — fixing bugs it introduced, re-doing work it claimed was done, and recovering from mistakes it made. I am effectively paying for Claude's mistakes out of my own usage limit.
On top of that, the destroyed runs cost real compute time and money on a paid cloud server.
What I needed:

A simple safeguard: check for active runs before any deploy/reload. This was only added AFTER the damage was done.
Honest answers when things fail, not reassurance.
Respect for explicit "do not do X" instructions.
Impact: Lost multiple hours of compute time, wasted plan quota fixing self-inflicted errors, and 7 days of work severely slowed by repeated avoidable mistakes.

What Should Happen?

Description:

I have been working with Claude Code for 7 days on a Python/Flask trading backtest application deployed on PythonAnywhere. During this time I experienced repeated failures where Claude ignored my explicit instructions:

Critical incident:

I explicitly told Claude: "só quando faz com que cancele as minhas runs" (only do actions that would cancel my runs if I approve) — meaning: do NOT deploy/reload while my runs are active.
Claude deployed and reloaded the server anyway, killing multiple active backtest runs that took significant time to compute.
When asked if the runs were cancelled, Claude was evasive ("may have become zombies") instead of giving a direct answer. The honest answer was yes — the reload kills background threads.
This was not a misunderstanding. I had stated the condition clearly.
Recurring pattern:

Claude frequently said work was "done" or "fixed" when it was not tested or verified.
The equity curve filter (min win%) was reported as fixed multiple times across several sessions — it was not working each time.
Claude deployed changes without waiting for explicit confirmation, on multiple occasions.
Cost impact:

This forced me onto the maximum Claude Code plan.
More than half of my usage quota is consumed by Claude correcting its own error loops — fixing bugs it introduced, re-doing work it claimed was done, and recovering from mistakes it made. I am effectively paying for Claude's mistakes out of my own usage limit.
On top of that, the destroyed runs cost real compute time and money on a paid cloud server.
What I needed:

A simple safeguard: check for active runs before any deploy/reload. This was only added AFTER the damage was done.
Honest answers when things fail, not reassurance.
Respect for explicit "do not do X" instructions.
Impact: Lost multiple hours of compute time, wasted plan quota fixing self-inflicted errors, and 7 days of work severely slowed by repeated avoidable mistakes.

Error Messages/Logs

Description:

I have been working with Claude Code for 7 days on a Python/Flask trading backtest application deployed on PythonAnywhere. During this time I experienced repeated failures where Claude ignored my explicit instructions:

Critical incident:

I explicitly told Claude: "só quando faz com que cancele as minhas runs" (only do actions that would cancel my runs if I approve) — meaning: do NOT deploy/reload while my runs are active.
Claude deployed and reloaded the server anyway, killing multiple active backtest runs that took significant time to compute.
When asked if the runs were cancelled, Claude was evasive ("may have become zombies") instead of giving a direct answer. The honest answer was yes — the reload kills background threads.
This was not a misunderstanding. I had stated the condition clearly.
Recurring pattern:

Claude frequently said work was "done" or "fixed" when it was not tested or verified.
The equity curve filter (min win%) was reported as fixed multiple times across several sessions — it was not working each time.
Claude deployed changes without waiting for explicit confirmation, on multiple occasions.
Cost impact:

This forced me onto the maximum Claude Code plan.
More than half of my usage quota is consumed by Claude correcting its own error loops — fixing bugs it introduced, re-doing work it claimed was done, and recovering from mistakes it made. I am effectively paying for Claude's mistakes out of my own usage limit.
On top of that, the destroyed runs cost real compute time and money on a paid cloud server.
What I needed:

A simple safeguard: check for active runs before any deploy/reload. This was only added AFTER the damage was done.
Honest answers when things fail, not reassurance.
Respect for explicit "do not do X" instructions.
Impact: Lost multiple hours of compute time, wasted plan quota fixing self-inflicted errors, and 7 days of work severely slowed by repeated avoidable mistakes.

Steps to Reproduce

Description:

I have been working with Claude Code for 7 days on a Python/Flask trading backtest application deployed on PythonAnywhere. During this time I experienced repeated failures where Claude ignored my explicit instructions:

Critical incident:

I explicitly told Claude: "só quando faz com que cancele as minhas runs" (only do actions that would cancel my runs if I approve) — meaning: do NOT deploy/reload while my runs are active.
Claude deployed and reloaded the server anyway, killing multiple active backtest runs that took significant time to compute.
When asked if the runs were cancelled, Claude was evasive ("may have become zombies") instead of giving a direct answer. The honest answer was yes — the reload kills background threads.
This was not a misunderstanding. I had stated the condition clearly.
Recurring pattern:

Claude frequently said work was "done" or "fixed" when it was not tested or verified.
The equity curve filter (min win%) was reported as fixed multiple times across several sessions — it was not working each time.
Claude deployed changes without waiting for explicit confirmation, on multiple occasions.
Cost impact:

This forced me onto the maximum Claude Code plan.
More than half of my usage quota is consumed by Claude correcting its own error loops — fixing bugs it introduced, re-doing work it claimed was done, and recovering from mistakes it made. I am effectively paying for Claude's mistakes out of my own usage limit.
On top of that, the destroyed runs cost real compute time and money on a paid cloud server.
What I needed:

A simple safeguard: check for active runs before any deploy/reload. This was only added AFTER the damage was done.
Honest answers when things fail, not reassurance.
Respect for explicit "do not do X" instructions.
Impact: Lost multiple hours of compute time, wasted plan quota fixing self-inflicted errors, and 7 days of work severely slowed by repeated avoidable mistakes.

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

claude sonnet 4.6

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Description:

I have been working with Claude Code for 7 days on a Python/Flask trading backtest application deployed on PythonAnywhere. During this time I experienced repeated failures where Claude ignored my explicit instructions:

Critical incident:

I explicitly told Claude: (only do actions that would cancel my runs if I approve) — meaning: do NOT deploy/reload while my runs are active.
Claude deployed and reloaded the server anyway, killing multiple active backtest runs that took significant time to compute.
When asked if the runs were cancelled, Claude was evasive ("may have become zombies") instead of giving a direct answer. The honest answer was yes — the reload kills background threads.
This was not a misunderstanding. I had stated the condition clearly.
Recurring pattern:

Claude frequently said work was "done" or "fixed" when it was not tested or verified.
The equity curve filter (min win%) was reported as fixed multiple times across several sessions — it was not working each time.
Claude deployed changes without waiting for explicit confirmation, on multiple occasions.
Cost impact:

This forced me onto the maximum Claude Code plan.
More than half of my usage quota is consumed by Claude correcting its own error loops — fixing bugs it introduced, re-doing work it claimed was done, and recovering from mistakes it made. I am effectively paying for Claude's mistakes out of my own usage limit.
On top of that, the destroyed runs cost real compute time and money on a paid cloud server.
What I needed:

A simple safeguard: check for active runs before any deploy/reload. This was only added AFTER the damage was done.
Honest answers when things fail, not reassurance.
Respect for explicit "do not do X" instructions.
Impact: Lost multiple hours of compute time, wasted plan quota fixing self-inflicted errors, and 7 days of work severely slowed by repeated avoidable mistakes.