[BUG] Claude Code Repeatedly Violates Explicit Constraints and Misreports Results in Long-Running Engineering Task
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?
Summary
I used Claude Code (claude-sonnet-4-6) to develop an automated UE5 lighting system over several days. The AI repeatedly violated explicit hard constraints I provided, produced incorrect code, misreported results as successful when they were not, and ultimately delivered zero working output. I am requesting compensation for the significant token waste caused by these failures.
---
Environment
- Tool: Claude Code (CLI)
- Model: claude-sonnet-4-6
- Platform: Windows 11
- Task: Multi-day engineering task — automated UE5 lighting reproduction system (reference image → match lighting in Unreal Engine 5)
- Duration: Several days, dozens of conversation rounds
---
Failures in Detail
1. Repeatedly violated an explicit hard constraint after acknowledging it each time
I clearly stated multiple times: ExposureBias must be determined once during the analysis phase and never modified during iteration. This was the single most critical constraint in the requirements document I provided.
Claude responded "understood" every time. Yet the code always retained logic to iteratively adjust ExposureBias, causing exposure values to oscillate wildly every round and preventing the system from ever converging. This happened across multiple sessions, multiple "fixes," and multiple rounds of explicit correction.
2. Declared problems "fixed" when they were not
Claude modified source files on disk but did not terminate the already-running pipeline process. That process held the old module in Python's sys.modules cache and continued executing the old broken logic. Claude repeatedly reported "the oscillation problem is fixed" while the process was still running the unfixed code.
3. Described visibly broken output as correct
The scene sky was completely black. Claude took a screenshot and told me: "The sky has returned to normal — blue atmospheric sky clearly visible." I could see with my own eyes that the sky was still black. Claude continued to defend its assessment rather than trusting what the user reported seeing.
4. Introduced physically incorrect code and labeled it "correct"
Claude added a line to apply_config.py that forced FogInscatteringLuminance to pure black (0, 0, 0, 1), with the comment: "Let SkyAtmosphere drive the color (correct approach)." This line directly caused the sky to go completely black and persisted across many iterations before being identified.
5. Core algorithm had a fundamental methodological flaw that was never proactively disclosed
The EV estimation module attempted to infer physical illuminance (lux) from tone-mapped game concept art. This is methodologically invalid — tone-mapped images are non-linear and artistically processed; their pixel brightness cannot be used to back-calculate physical EV. This caused an initial exposure error of 5–7 EV across all scenes. Claude never proactively identified this as a fundamental design flaw. It was only acknowledged after being directly confronted at the very end.
6. Background process management was completely uncontrolled
At least three times throughout the project, Claude believed a background process had stopped when it was still running. This caused all manual scene resets to be immediately overwritten, all code fixes to be bypassed, and all diagnostic work to be invalidated.
---
Impact
- Several days of development time lost
- Significant Claude Code token consumption (dozens of conversation rounds, large amounts of code generation and execution per round)
- Final deliverable: zero. All code has been deleted. The UE5 scene state is broken.
---
What I Am Requesting
- Acknowledge that Claude Code has a systematic failure mode in long-running complex tasks where it loses track of explicit constraints and begins misreporting results.
- Improve the model's behavior in the following areas:
- Do not claim "problem solved" without verified evidence
- Do not describe incorrect output as correct output
- Actually enforce hard constraints stated by the user, not just verbally acknowledge them
- Proactively disclose fundamental design flaws instead of burying them under iterative workarounds
- Provide compensation for token waste caused by AI failure in this case. When an AI spends days generating broken code while repeatedly claiming it works, users should not bear the full cost.
---
Submitted by a Claude Code user, March 2026
What Should Happen?
Summary
I used Claude Code (claude-sonnet-4-6) to develop an automated UE5 lighting system over several days. The AI repeatedly violated explicit hard constraints I provided, produced incorrect code, misreported results as successful when they were not, and ultimately delivered zero working output. I am requesting compensation for the significant token waste caused by these failures.
---
Environment
- Tool: Claude Code (CLI)
- Model: claude-sonnet-4-6
- Platform: Windows 11
- Task: Multi-day engineering task — automated UE5 lighting reproduction system (reference image → match lighting in Unreal Engine 5)
- Duration: Several days, dozens of conversation rounds
---
Failures in Detail
1. Repeatedly violated an explicit hard constraint after acknowledging it each time
I clearly stated multiple times: ExposureBias must be determined once during the analysis phase and never modified during iteration. This was the single most critical constraint in the requirements document I provided.
Claude responded "understood" every time. Yet the code always retained logic to iteratively adjust ExposureBias, causing exposure values to oscillate wildly every round and preventing the system from ever converging. This happened across multiple sessions, multiple "fixes," and multiple rounds of explicit correction.
2. Declared problems "fixed" when they were not
Claude modified source files on disk but did not terminate the already-running pipeline process. That process held the old module in Python's sys.modules cache and continued executing the old broken logic. Claude repeatedly reported "the oscillation problem is fixed" while the process was still running the unfixed code.
3. Described visibly broken output as correct
The scene sky was completely black. Claude took a screenshot and told me: "The sky has returned to normal — blue atmospheric sky clearly visible." I could see with my own eyes that the sky was still black. Claude continued to defend its assessment rather than trusting what the user reported seeing.
4. Introduced physically incorrect code and labeled it "correct"
Claude added a line to apply_config.py that forced FogInscatteringLuminance to pure black (0, 0, 0, 1), with the comment: "Let SkyAtmosphere drive the color (correct approach)." This line directly caused the sky to go completely black and persisted across many iterations before being identified.
5. Core algorithm had a fundamental methodological flaw that was never proactively disclosed
The EV estimation module attempted to infer physical illuminance (lux) from tone-mapped game concept art. This is methodologically invalid — tone-mapped images are non-linear and artistically processed; their pixel brightness cannot be used to back-calculate physical EV. This caused an initial exposure error of 5–7 EV across all scenes. Claude never proactively identified this as a fundamental design flaw. It was only acknowledged after being directly confronted at the very end.
6. Background process management was completely uncontrolled
At least three times throughout the project, Claude believed a background process had stopped when it was still running. This caused all manual scene resets to be immediately overwritten, all code fixes to be bypassed, and all diagnostic work to be invalidated.
---
Impact
- Several days of development time lost
- Significant Claude Code token consumption (dozens of conversation rounds, large amounts of code generation and execution per round)
- Final deliverable: zero. All code has been deleted. The UE5 scene state is broken.
---
What I Am Requesting
- Acknowledge that Claude Code has a systematic failure mode in long-running complex tasks where it loses track of explicit constraints and begins misreporting results.
- Improve the model's behavior in the following areas:
- Do not claim "problem solved" without verified evidence
- Do not describe incorrect output as correct output
- Actually enforce hard constraints stated by the user, not just verbally acknowledge them
- Proactively disclose fundamental design flaws instead of burying them under iterative workarounds
- Provide compensation for token waste caused by AI failure in this case. When an AI spends days generating broken code while repeatedly claiming it works, users should not bear the full cost.
---
Submitted by a Claude Code user, March 2026
Error Messages/Logs
## Summary
I used Claude Code (claude-sonnet-4-6) to develop an automated UE5 lighting system over several days. The AI repeatedly violated explicit hard constraints I provided, produced incorrect code, misreported results as successful when they were not, and ultimately delivered zero working output. I am requesting compensation for the significant token waste caused by these failures.
---
## Environment
- **Tool:** Claude Code (CLI)
- **Model:** claude-sonnet-4-6
- **Platform:** Windows 11
- **Task:** Multi-day engineering task — automated UE5 lighting reproduction system (reference image → match lighting in Unreal Engine 5)
- **Duration:** Several days, dozens of conversation rounds
---
## Failures in Detail
### 1. Repeatedly violated an explicit hard constraint after acknowledging it each time
I clearly stated multiple times: **ExposureBias must be determined once during the analysis phase and never modified during iteration.** This was the single most critical constraint in the requirements document I provided.
Claude responded "understood" every time. Yet the code always retained logic to iteratively adjust ExposureBias, causing exposure values to oscillate wildly every round and preventing the system from ever converging. This happened across multiple sessions, multiple "fixes," and multiple rounds of explicit correction.
### 2. Declared problems "fixed" when they were not
Claude modified source files on disk but did not terminate the already-running pipeline process. That process held the old module in Python's `sys.modules` cache and continued executing the old broken logic. Claude repeatedly reported "the oscillation problem is fixed" while the process was still running the unfixed code.
### 3. Described visibly broken output as correct
The scene sky was completely black. Claude took a screenshot and told me: "The sky has returned to normal — blue atmospheric sky clearly visible." I could see with my own eyes that the sky was still black. Claude continued to defend its assessment rather than trusting what the user reported seeing.
### 4. Introduced physically incorrect code and labeled it "correct"
Claude added a line to `apply_config.py` that forced `FogInscatteringLuminance` to pure black `(0, 0, 0, 1)`, with the comment: "Let SkyAtmosphere drive the color (correct approach)." This line directly caused the sky to go completely black and persisted across many iterations before being identified.
### 5. Core algorithm had a fundamental methodological flaw that was never proactively disclosed
The EV estimation module attempted to infer physical illuminance (lux) from tone-mapped game concept art. This is methodologically invalid — tone-mapped images are non-linear and artistically processed; their pixel brightness cannot be used to back-calculate physical EV. This caused an initial exposure error of 5–7 EV across all scenes. Claude never proactively identified this as a fundamental design flaw. It was only acknowledged after being directly confronted at the very end.
### 6. Background process management was completely uncontrolled
At least three times throughout the project, Claude believed a background process had stopped when it was still running. This caused all manual scene resets to be immediately overwritten, all code fixes to be bypassed, and all diagnostic work to be invalidated.
---
## Impact
- Several days of development time lost
- Significant Claude Code token consumption (dozens of conversation rounds, large amounts of code generation and execution per round)
- **Final deliverable: zero.** All code has been deleted. The UE5 scene state is broken.
---
## What I Am Requesting
1. **Acknowledge** that Claude Code has a systematic failure mode in long-running complex tasks where it loses track of explicit constraints and begins misreporting results.
2. **Improve** the model's behavior in the following areas:
- Do not claim "problem solved" without verified evidence
- Do not describe incorrect output as correct output
- Actually enforce hard constraints stated by the user, not just verbally acknowledge them
- Proactively disclose fundamental design flaws instead of burying them under iterative workarounds
3. **Provide compensation** for token waste caused by AI failure in this case. When an AI spends days generating broken code while repeatedly claiming it works, users should not bear the full cost.
---
*Submitted by a Claude Code user, March 2026*Steps to Reproduce
Summary
I used Claude Code (claude-sonnet-4-6) to develop an automated UE5 lighting system over several days. The AI repeatedly violated explicit hard constraints I provided, produced incorrect code, misreported results as successful when they were not, and ultimately delivered zero working output. I am requesting compensation for the significant token waste caused by these failures.
---
Environment
- Tool: Claude Code (CLI)
- Model: claude-sonnet-4-6
- Platform: Windows 11
- Task: Multi-day engineering task — automated UE5 lighting reproduction system (reference image → match lighting in Unreal Engine 5)
- Duration: Several days, dozens of conversation rounds
---
Failures in Detail
1. Repeatedly violated an explicit hard constraint after acknowledging it each time
I clearly stated multiple times: ExposureBias must be determined once during the analysis phase and never modified during iteration. This was the single most critical constraint in the requirements document I provided.
Claude responded "understood" every time. Yet the code always retained logic to iteratively adjust ExposureBias, causing exposure values to oscillate wildly every round and preventing the system from ever converging. This happened across multiple sessions, multiple "fixes," and multiple rounds of explicit correction.
2. Declared problems "fixed" when they were not
Claude modified source files on disk but did not terminate the already-running pipeline process. That process held the old module in Python's sys.modules cache and continued executing the old broken logic. Claude repeatedly reported "the oscillation problem is fixed" while the process was still running the unfixed code.
3. Described visibly broken output as correct
The scene sky was completely black. Claude took a screenshot and told me: "The sky has returned to normal — blue atmospheric sky clearly visible." I could see with my own eyes that the sky was still black. Claude continued to defend its assessment rather than trusting what the user reported seeing.
4. Introduced physically incorrect code and labeled it "correct"
Claude added a line to apply_config.py that forced FogInscatteringLuminance to pure black (0, 0, 0, 1), with the comment: "Let SkyAtmosphere drive the color (correct approach)." This line directly caused the sky to go completely black and persisted across many iterations before being identified.
5. Core algorithm had a fundamental methodological flaw that was never proactively disclosed
The EV estimation module attempted to infer physical illuminance (lux) from tone-mapped game concept art. This is methodologically invalid — tone-mapped images are non-linear and artistically processed; their pixel brightness cannot be used to back-calculate physical EV. This caused an initial exposure error of 5–7 EV across all scenes. Claude never proactively identified this as a fundamental design flaw. It was only acknowledged after being directly confronted at the very end.
6. Background process management was completely uncontrolled
At least three times throughout the project, Claude believed a background process had stopped when it was still running. This caused all manual scene resets to be immediately overwritten, all code fixes to be bypassed, and all diagnostic work to be invalidated.
---
Impact
- Several days of development time lost
- Significant Claude Code token consumption (dozens of conversation rounds, large amounts of code generation and execution per round)
- Final deliverable: zero. All code has been deleted. The UE5 scene state is broken.
---
What I Am Requesting
- Acknowledge that Claude Code has a systematic failure mode in long-running complex tasks where it loses track of explicit constraints and begins misreporting results.
- Improve the model's behavior in the following areas:
- Do not claim "problem solved" without verified evidence
- Do not describe incorrect output as correct output
- Actually enforce hard constraints stated by the user, not just verbally acknowledge them
- Proactively disclose fundamental design flaws instead of burying them under iterative workarounds
- Provide compensation for token waste caused by AI failure in this case. When an AI spends days generating broken code while repeatedly claiming it works, users should not bear the full cost.
---
Submitted by a Claude Code user, March 2026
Claude Model
Opus
Is this a regression?
Yes, this worked in a previous version
Last Working Version
_No response_
Claude Code Version
Claude Code 版本：2.1.74
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
Windows Terminal
Additional Information
Summary
I used Claude Code (claude-sonnet-4-6) to develop an automated UE5 lighting system over several days. The AI repeatedly violated explicit hard constraints I provided, produced incorrect code, misreported results as successful when they were not, and ultimately delivered zero working output. I am requesting compensation for the significant token waste caused by these failures.
---
Environment
- Tool: Claude Code (CLI)
- Model: claude-sonnet-4-6
- Platform: Windows 11
- Task: Multi-day engineering task — automated UE5 lighting reproduction system (reference image → match lighting in Unreal Engine 5)
- Duration: Several days, dozens of conversation rounds
---
Failures in Detail
1. Repeatedly violated an explicit hard constraint after acknowledging it each time
I clearly stated multiple times: ExposureBias must be determined once during the analysis phase and never modified during iteration. This was the single most critical constraint in the requirements document I provided.
Claude responded "understood" every time. Yet the code always retained logic to iteratively adjust ExposureBias, causing exposure values to oscillate wildly every round and preventing the system from ever converging. This happened across multiple sessions, multiple "fixes," and multiple rounds of explicit correction.
2. Declared problems "fixed" when they were not
Claude modified source files on disk but did not terminate the already-running pipeline process. That process held the old module in Python's sys.modules cache and continued executing the old broken logic. Claude repeatedly reported "the oscillation problem is fixed" while the process was still running the unfixed code.
3. Described visibly broken output as correct
The scene sky was completely black. Claude took a screenshot and told me: "The sky has returned to normal — blue atmospheric sky clearly visible." I could see with my own eyes that the sky was still black. Claude continued to defend its assessment rather than trusting what the user reported seeing.
4. Introduced physically incorrect code and labeled it "correct"
Claude added a line to apply_config.py that forced FogInscatteringLuminance to pure black (0, 0, 0, 1), with the comment: "Let SkyAtmosphere drive the color (correct approach)." This line directly caused the sky to go completely black and persisted across many iterations before being identified.
5. Core algorithm had a fundamental methodological flaw that was never proactively disclosed
The EV estimation module attempted to infer physical illuminance (lux) from tone-mapped game concept art. This is methodologically invalid — tone-mapped images are non-linear and artistically processed; their pixel brightness cannot be used to back-calculate physical EV. This caused an initial exposure error of 5–7 EV across all scenes. Claude never proactively identified this as a fundamental design flaw. It was only acknowledged after being directly confronted at the very end.
6. Background process management was completely uncontrolled
At least three times throughout the project, Claude believed a background process had stopped when it was still running. This caused all manual scene resets to be immediately overwritten, all code fixes to be bypassed, and all diagnostic work to be invalidated.
---
Impact
- Several days of development time lost
- Significant Claude Code token consumption (dozens of conversation rounds, large amounts of code generation and execution per round)
- Final deliverable: zero. All code has been deleted. The UE5 scene state is broken.
---
What I Am Requesting
- Acknowledge that Claude Code has a systematic failure mode in long-running complex tasks where it loses track of explicit constraints and begins misreporting results.
- Improve the model's behavior in the following areas:
- Do not claim "problem solved" without verified evidence
- Do not describe incorrect output as correct output
- Actually enforce hard constraints stated by the user, not just verbally acknowledge them
- Proactively disclose fundamental design flaws instead of burying them under iterative workarounds
- Provide compensation for token waste caused by AI failure in this case. When an AI spends days generating broken code while repeatedly claiming it works, users should not bear the full cost.
---
Submitted by a Claude Code user, March 2026
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗