[MODEL]

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 made incorrect assumptions about my project

What You Asked Claude to Do

I asked Claude to debug why a Python function get_files() returned the wrong result when called from my application (HTP), but the correct result when called directly via PowerShell — same .pyd, same Python interpreter, same arguments. All of this was code written by claude in the first place.

What Claude Actually Did

Over ~4 hours, Claude proposed and pursued ~15 different theories about indirect causes:

1. C++ timezone/margin bug
2. Stale .pyd from setuptools wheel cache
3. uv vs pip vs venv installation paths
4. uv cache not cleared
5. uv run auto-syncing with stale local copies
6. MSBuild target not running due to file mtime comparison
7. Mutagen file sync not propagating mtimes
8. robocopy timestamp-based skip logic
9. Multiple .venv locations confusing which python.exe gets called
10. C# #if DEBUG not compiled into the right DLL
11. Working directory differences between launches
12. Cross-bitness process launch (32-bit parent, 64-bit child)
13. File path slash format
14. Read operations corrupting persistent header copies
15. PySys_WriteStderr buffering not reaching captured pipe

For each theory, Claude asked me to: rebuild HTP, rerun setup_venv.bat, delete cache files, edit MSBuild targets, write hash check scripts, force pip reinstall, clear marker files, etc.

I told Claude multiple times "this is crazy", "I rebuilt", "stop assuming stale". Claude kept proposing more elaborate theories.

The actual bug: Claude had earlier in the same session added get_files() to r2DBreader/r2DBreader.py but forgot to re-export it from r2DBreader/__init__.py. So module 'r2DBreader' has no attribute 'get_files'. The calling code had a try/except AttributeError that fell through to a wrong fallback silently.

Claude only found this after finally adding a debug print right at the failure site. That print immediately showed: "module 'r2DBreader' has no attribute 'get_files'". Bug solved in 1 line — adding get_files to the imports in __init__.py. This added was done at user requesting it.

The signal Claude missed: earlier in the session, we ran dir(r2DBreader_core) and confirmed the .pyd had get_files. Claude concluded "the .pyd is fine" and pursued environmental theories — but never thought to also check dir(r2DBreader) (the wrapper package, which is a DIFFERENT Python object from the C
extension). The two were treated as one entity.

Pattern to avoid: when something fails with "no attribute" or "wrong result, same code", first action should be inspecting the actual failing object (dir(), __file__, version), not theorizing about caches/builds/sync/environment. Caches are a convenient theory because they explain anything — which is exactly why
they're dangerous.

Expected Behavior

Claude should have:

1. As the FIRST debugging step, inspected the actual failing object: print(dir(r2DBreader)) and print(dir(r2DBreader_core)) separately, comparing the two.
2. Recognized that the wrapper package and the C extension are two distinct Python objects with independent namespaces.
3. Found within minutes that get_files was in the .pyd but missing from the wrapper package's __init__.py.
4. Fixed the 1-line export.
5. Not proposed rebuilds, cache clears, or environmental theories until basic state inspection had been done.

When the user said "I rebuilt", "I deleted that", "stop assuming stale" — Claude should have trusted those statements instead of proposing more elaborate caching/sync theories that required the user to be wrong about basic facts.

Files Affected — leave it nearly empty since this isn't a "Claude touched files unexpectedly" issue:
N/A — this is a debugging-strategy issue, not a file modification issue.

(Claude did edit the right file at the end — r2DBreader/__init__.py — to add the missing export. The complaint is about the 4 hours of wrong direction before getting there.)

Files Affected

Permission Mode

Accept Edits was ON (auto-accepting changes)

Can You Reproduce This?

No, only happened once

Steps to Reproduce

_No response_

Claude Model

Opus

Relevant Conversation

Impact

Medium - Extra work to undo changes

Claude Code Version

2.1.78

Platform

Anthropic API

Additional Context

_No response_