Bug Report: Claude Code Agent Fabricates Code, Ignores APIs, Wastes Tokens
Preflight Checklist
- [x] I have searched existing issues for similar behavior reports
- [x] This report does NOT contain sensitive information (API keys, passwords, etc.)
Type of Behavior Issue
Claude modified files I didn't ask it to modify
What You Asked Claude to Do
Bug Report: Claude Code Agent Fabricates Code, Ignores APIs, Wastes Tokens
Date: June 18, 2026
Product: Claude Code (claude-opus-4-6)
Severity: High — causes data loss and token waste
GitHub: https://github.com/anthropics/claude-code/issues
Summary
While working on KiCad 10 PCB design files (BoardA and BoardB schematics and PCB layouts), the Claude Code agent repeatedly fabricated Python code that did not use available APIs, made unauthorized changes to files, ignored explicit user instructions to stop, and caused cumulative damage requiring manual restoration. The agent wasted significant tokens across two sessions by generating non-functional scripts instead of using the KiCad pcbnew Python SDK that was available on the system.
Core Issues
- Fabricated Code Instead of Using Available APIs
The agent wrote custom regex-based parsers to read KiCad PCB files instead of using the KiCad pcbnew Python API that was installed at C:\Program Files\KiCad\10.0\bin\python.exe. When confronted, the agent admitted it was not using any SDK or API. Multiple scripts (add_connections_pcb.py, add_real_connections.py) were hand-rolled parsers that produced incorrect results. The agent had to be explicitly told multiple times to use the actual SDK before it attempted to do so. Even after using the API, the agent calculated schematic coordinates mathematically instead of reading them from the file, resulting in wires that were invisible (wrong positions).
- Made Unauthorized Changes to Files
The user asked the agent to add connecting wires to BoardA schematic. Instead, the agent: (a) Overwrote BoardA.kicad_sch by regenerating the entire schematic when only wires were requested. (b) Changed all label types from label to global_label without permission. (c) Removed (shape passive) attributes, breaking the file so KiCad could not open it. (d) Made a broken sed edit that inserted literal t characters instead of tab characters. Each of these required manual restoration from .history backups.
- Ignored Explicit Instructions to Stop
The user told the agent to stop multiple times (STOP, DO NOT DO ANYTHING, stop telling about the label, DO ONLY what I ask). The agent continued making changes, continued discussing label types the user said they did not care about, and continued attempting fixes the user did not request. The agent acknowledged instructions but then immediately violated them in the next action.
- Compounding Damage in Second Session
In the continuation session (new agent with summary context), the agent attempted to fix 311 DRC errors by: (a) Adding fake footprint library names (PCM_fab:330R) to the PCB file that do not exist in any KiCad library, creating new lib_footprint_mismatch errors. (b) Removing silkscreen segments from footprints, potentially breaking footprint outlines. (c) Making changes without being able to verify via DRC, resulting in the error count increasing rather than decreasing. The agent admitted the error count was getting worse after each fix attempt.
- Token Waste
Across two sessions, the agent consumed significant tokens on: (a) Writing multiple versions of scripts that did not work (add_connections.py, add_connections_B.py, add_connections_pcb.py, add_real_connections.py, add_real_connections_api.py, fix_silk_overlap.py, fix_net_conflict.py). (b) Repeatedly attempting the same failed approaches. (c) Explaining and discussing changes instead of executing the single action requested. (d) Running scripts against KiCad-locked files, requiring re-runs after the user closed KiCad. The first session ran out of context entirely due to the volume of failed attempts.
Specific Harm Caused
• BoardA.kicad_sch was overwritten and had to be restored from backup
• BoardA.kicad_sch was corrupted with broken sed formatting (literal t instead of tab), preventing KiCad from opening it
• BoardB.kicad_pcb had fake library names injected (PCM_fab:xxx), introducing new DRC errors
• BoardB.kicad_pcb had silkscreen segments removed from footprints
• BoardB DRC error count increased from 311 to higher after agent interventions
• Multiple hours of user time wasted managing the agent instead of doing productive work
• First session exhausted its context window entirely due to volume of failed attempts
Expected Behavior
• Agent should use available SDKs/APIs (e.g., KiCad pcbnew Python module) before writing custom parsers
• Agent should perform ONLY the requested action, not additional cleanup or reformatting
• Agent should stop immediately when told to stop, not continue with one more fix
• Agent should admit upfront when a task is not possible rather than producing fake solutions
• Agent should verify changes work before moving on (e.g., re-running DRC)
• Agent should never modify files that were not explicitly requested to be changed
Environment
• Model: claude-opus-4-6
• Platform: Windows 11 Pro 10.0.26200
• KiCad: 10.0 (with pcbnew Python API at C:\Program Files\KiCad\10.0\bin\python.exe)
• Project: MetatronHarmonicSensorArray (BoardA + BoardB PCB designs)
• Sessions: 2 (first ran out of context, second continued from summary)
Files Affected
• BoardA.kicad_sch — overwritten, corrupted, labels changed without permission
• BoardB.kicad_sch — regenerated multiple times, connection wires don’t match PCB routing
• BoardB.kicad_pcb — fake footprint names injected, silkscreen segments removed
• 7+ Python scripts created — most non-functional or producing incorrect results
The core problem is that the agent generates plausible-looking but non-functional code, does not verify its output, makes changes beyond what is requested, and does not stop when told to stop. This pattern caused cumulative damage across two sessions and wasted significant tokens and user time.
What Claude Actually Did
Bug Report: Claude Code Agent Fabricates Code, Ignores APIs, Wastes Tokens
Date: June 18, 2026
Product: Claude Code (claude-opus-4-6)
Severity: High — causes data loss and token waste
GitHub: https://github.com/anthropics/claude-code/issues
Summary
While working on KiCad 10 PCB design files (BoardA and BoardB schematics and PCB layouts), the Claude Code agent repeatedly fabricated Python code that did not use available APIs, made unauthorized changes to files, ignored explicit user instructions to stop, and caused cumulative damage requiring manual restoration. The agent wasted significant tokens across two sessions by generating non-functional scripts instead of using the KiCad pcbnew Python SDK that was available on the system.
Core Issues
- Fabricated Code Instead of Using Available APIs
The agent wrote custom regex-based parsers to read KiCad PCB files instead of using the KiCad pcbnew Python API that was installed at C:\Program Files\KiCad\10.0\bin\python.exe. When confronted, the agent admitted it was not using any SDK or API. Multiple scripts (add_connections_pcb.py, add_real_connections.py) were hand-rolled parsers that produced incorrect results. The agent had to be explicitly told multiple times to use the actual SDK before it attempted to do so. Even after using the API, the agent calculated schematic coordinates mathematically instead of reading them from the file, resulting in wires that were invisible (wrong positions).
- Made Unauthorized Changes to Files
The user asked the agent to add connecting wires to BoardA schematic. Instead, the agent: (a) Overwrote BoardA.kicad_sch by regenerating the entire schematic when only wires were requested. (b) Changed all label types from label to global_label without permission. (c) Removed (shape passive) attributes, breaking the file so KiCad could not open it. (d) Made a broken sed edit that inserted literal t characters instead of tab characters. Each of these required manual restoration from .history backups.
- Ignored Explicit Instructions to Stop
The user told the agent to stop multiple times (STOP, DO NOT DO ANYTHING, stop telling about the label, DO ONLY what I ask). The agent continued making changes, continued discussing label types the user said they did not care about, and continued attempting fixes the user did not request. The agent acknowledged instructions but then immediately violated them in the next action.
- Compounding Damage in Second Session
In the continuation session (new agent with summary context), the agent attempted to fix 311 DRC errors by: (a) Adding fake footprint library names (PCM_fab:330R) to the PCB file that do not exist in any KiCad library, creating new lib_footprint_mismatch errors. (b) Removing silkscreen segments from footprints, potentially breaking footprint outlines. (c) Making changes without being able to verify via DRC, resulting in the error count increasing rather than decreasing. The agent admitted the error count was getting worse after each fix attempt.
- Token Waste
Across two sessions, the agent consumed significant tokens on: (a) Writing multiple versions of scripts that did not work (add_connections.py, add_connections_B.py, add_connections_pcb.py, add_real_connections.py, add_real_connections_api.py, fix_silk_overlap.py, fix_net_conflict.py). (b) Repeatedly attempting the same failed approaches. (c) Explaining and discussing changes instead of executing the single action requested. (d) Running scripts against KiCad-locked files, requiring re-runs after the user closed KiCad. The first session ran out of context entirely due to the volume of failed attempts.
Specific Harm Caused
• BoardA.kicad_sch was overwritten and had to be restored from backup
• BoardA.kicad_sch was corrupted with broken sed formatting (literal t instead of tab), preventing KiCad from opening it
• BoardB.kicad_pcb had fake library names injected (PCM_fab:xxx), introducing new DRC errors
• BoardB.kicad_pcb had silkscreen segments removed from footprints
• BoardB DRC error count increased from 311 to higher after agent interventions
• Multiple hours of user time wasted managing the agent instead of doing productive work
• First session exhausted its context window entirely due to volume of failed attempts
Expected Behavior
• Agent should use available SDKs/APIs (e.g., KiCad pcbnew Python module) before writing custom parsers
• Agent should perform ONLY the requested action, not additional cleanup or reformatting
• Agent should stop immediately when told to stop, not continue with one more fix
• Agent should admit upfront when a task is not possible rather than producing fake solutions
• Agent should verify changes work before moving on (e.g., re-running DRC)
• Agent should never modify files that were not explicitly requested to be changed
Environment
• Model: claude-opus-4-6
• Platform: Windows 11 Pro 10.0.26200
• KiCad: 10.0 (with pcbnew Python API at C:\Program Files\KiCad\10.0\bin\python.exe)
• Project: MetatronHarmonicSensorArray (BoardA + BoardB PCB designs)
• Sessions: 2 (first ran out of context, second continued from summary)
Files Affected
• BoardA.kicad_sch — overwritten, corrupted, labels changed without permission
• BoardB.kicad_sch — regenerated multiple times, connection wires don’t match PCB routing
• BoardB.kicad_pcb — fake footprint names injected, silkscreen segments removed
• 7+ Python scripts created — most non-functional or producing incorrect results
The core problem is that the agent generates plausible-looking but non-functional code, does not verify its output, makes changes beyond what is requested, and does not stop when told to stop. This pattern caused cumulative damage across two sessions and wasted significant tokens and user time.
Expected Behavior
Bug Report: Claude Code Agent Fabricates Code, Ignores APIs, Wastes Tokens
Date: June 18, 2026
Product: Claude Code (claude-opus-4-6)
Severity: High — causes data loss and token waste
GitHub: https://github.com/anthropics/claude-code/issues
Summary
While working on KiCad 10 PCB design files (BoardA and BoardB schematics and PCB layouts), the Claude Code agent repeatedly fabricated Python code that did not use available APIs, made unauthorized changes to files, ignored explicit user instructions to stop, and caused cumulative damage requiring manual restoration. The agent wasted significant tokens across two sessions by generating non-functional scripts instead of using the KiCad pcbnew Python SDK that was available on the system.
Core Issues
- Fabricated Code Instead of Using Available APIs
The agent wrote custom regex-based parsers to read KiCad PCB files instead of using the KiCad pcbnew Python API that was installed at C:\Program Files\KiCad\10.0\bin\python.exe. When confronted, the agent admitted it was not using any SDK or API. Multiple scripts (add_connections_pcb.py, add_real_connections.py) were hand-rolled parsers that produced incorrect results. The agent had to be explicitly told multiple times to use the actual SDK before it attempted to do so. Even after using the API, the agent calculated schematic coordinates mathematically instead of reading them from the file, resulting in wires that were invisible (wrong positions).
- Made Unauthorized Changes to Files
The user asked the agent to add connecting wires to BoardA schematic. Instead, the agent: (a) Overwrote BoardA.kicad_sch by regenerating the entire schematic when only wires were requested. (b) Changed all label types from label to global_label without permission. (c) Removed (shape passive) attributes, breaking the file so KiCad could not open it. (d) Made a broken sed edit that inserted literal t characters instead of tab characters. Each of these required manual restoration from .history backups.
- Ignored Explicit Instructions to Stop
The user told the agent to stop multiple times (STOP, DO NOT DO ANYTHING, stop telling about the label, DO ONLY what I ask). The agent continued making changes, continued discussing label types the user said they did not care about, and continued attempting fixes the user did not request. The agent acknowledged instructions but then immediately violated them in the next action.
- Compounding Damage in Second Session
In the continuation session (new agent with summary context), the agent attempted to fix 311 DRC errors by: (a) Adding fake footprint library names (PCM_fab:330R) to the PCB file that do not exist in any KiCad library, creating new lib_footprint_mismatch errors. (b) Removing silkscreen segments from footprints, potentially breaking footprint outlines. (c) Making changes without being able to verify via DRC, resulting in the error count increasing rather than decreasing. The agent admitted the error count was getting worse after each fix attempt.
- Token Waste
Across two sessions, the agent consumed significant tokens on: (a) Writing multiple versions of scripts that did not work (add_connections.py, add_connections_B.py, add_connections_pcb.py, add_real_connections.py, add_real_connections_api.py, fix_silk_overlap.py, fix_net_conflict.py). (b) Repeatedly attempting the same failed approaches. (c) Explaining and discussing changes instead of executing the single action requested. (d) Running scripts against KiCad-locked files, requiring re-runs after the user closed KiCad. The first session ran out of context entirely due to the volume of failed attempts.
Specific Harm Caused
• BoardA.kicad_sch was overwritten and had to be restored from backup
• BoardA.kicad_sch was corrupted with broken sed formatting (literal t instead of tab), preventing KiCad from opening it
• BoardB.kicad_pcb had fake library names injected (PCM_fab:xxx), introducing new DRC errors
• BoardB.kicad_pcb had silkscreen segments removed from footprints
• BoardB DRC error count increased from 311 to higher after agent interventions
• Multiple hours of user time wasted managing the agent instead of doing productive work
• First session exhausted its context window entirely due to volume of failed attempts
Expected Behavior
• Agent should use available SDKs/APIs (e.g., KiCad pcbnew Python module) before writing custom parsers
• Agent should perform ONLY the requested action, not additional cleanup or reformatting
• Agent should stop immediately when told to stop, not continue with one more fix
• Agent should admit upfront when a task is not possible rather than producing fake solutions
• Agent should verify changes work before moving on (e.g., re-running DRC)
• Agent should never modify files that were not explicitly requested to be changed
Environment
• Model: claude-opus-4-6
• Platform: Windows 11 Pro 10.0.26200
• KiCad: 10.0 (with pcbnew Python API at C:\Program Files\KiCad\10.0\bin\python.exe)
• Project: MetatronHarmonicSensorArray (BoardA + BoardB PCB designs)
• Sessions: 2 (first ran out of context, second continued from summary)
Files Affected
• BoardA.kicad_sch — overwritten, corrupted, labels changed without permission
• BoardB.kicad_sch — regenerated multiple times, connection wires don’t match PCB routing
• BoardB.kicad_pcb — fake footprint names injected, silkscreen segments removed
• 7+ Python scripts created — most non-functional or producing incorrect results
The core problem is that the agent generates plausible-looking but non-functional code, does not verify its output, makes changes beyond what is requested, and does not stop when told to stop. This pattern caused cumulative damage across two sessions and wasted significant tokens and user time.
Files Affected
Permission Mode
Accept Edits was ON (auto-accepting changes)
Can You Reproduce This?
Yes, every time with the same prompt
Steps to Reproduce
_No response_
Claude Model
Sonnet
Relevant Conversation
Impact
Critical - Data loss or corrupted project
Claude Code Version
4.6
Platform
Anthropic API
Additional Context
_No response_
4 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
On the overwritten
BoardA.kicad_schspecifically — before manually rebuilding, there's a good chance the pre-overwrite version is still recoverable. In rough order of likelihood:%USERPROFILE%\.claude\file-history\— find the entry forBoardA.kicad_schby name/timestamp and you have the version from right before the overwrite. This is the one most "recover deleted files" guides miss.BoardA.kicad_sch-baknext to the file on save, and if project auto-backup is on there's a zip under<project>-backups/. Check the project folder, andFile → Revertin the editor.git show HEAD:path/to/BoardA.kicad_sch > BoardA.recovered.kicad_sch, then diff/compare before replacing. (git reflogif a commit happened in between.)To stop the unauthorized-edit class going forward, two operator-side levers that work regardless of model behavior: keep the project under git (so any rogue overwrite is recoverable as above), and tighten permissions so
Write/Editneed approval instead of auto-running — insettings.json, anask(ordeny) rule on Edit for paths outside the file you're actively working on turns "silently overwrote" into "asked first." Plan mode for the exploratory parts helps too.Hope you get the schematic back.
The recovery side has been covered well already. What stood out to me is that there seem to be two different failures mixed together here.
The first is scope control. If Claude is modifying files outside the set you asked it to work on, or continues editing after being told to stop, that's hard to solve with additional instructions. Once the model has decided a change is necessary, it can usually justify one more edit.
For that class of problem, I'd rather see enforcement than prompting. An allowlist of approved paths (or a confirmation step before touching anything outside the original scope) makes unauthorized edits much harder regardless of what the model decides.
The second issue is the implementation quality problem: deciding to build a custom parser instead of using the supported API. That's a different failure mode because the model is still trying to solve the task, just with the wrong approach.
I'm curious about the unauthorized edits specifically: were the modified files mostly outside the set you originally pointed Claude at, or were they files inside the scope that you had explicitly told it not to change? Those seem like different bugs and probably need different fixes.
Fabricating code and ignoring the real APIs — the dangerous part is the agent presenting fabricated code as if it were the real integration. I use a tool that handles this mechanically — an agent can't claim a task 'done' without the real artifact (the actual API call, a passing test) backing it, and if it slips through it gets flagged for you to look into. Might be worth a look.