[Bug] Claude Code refusing capable tasks without checking codebase first
I have been complaining about this now for some time and nothing gets done. Since you guys did an update, you've completely broken it and this is what I'm facing constantly. It's with everything. My whole workflow is broken as it refuses to do anything. It doesn't even check. It just says no or I can't do it. We've had months of it working absolutely perfectly and doing great and now we can't build anything We can't even run anything because it's refusing to work
Bug Description
Subject: Claude Code refusing tasks it can do, defaulting to "no"
I've been using Claude Code daily for months to manage a Telegram bot orchestrator. Recently Claude has
started refusing tasks it's fully capable of, without even checking the codebase first.
Example from today:
- I asked Claude to close a Telegram topic
- Claude immediately said "I don't have the ability to close or delete Telegram topics - that's an admin
action that needs to be done directly in Telegram"
- This is false. The codebase has session_manager.py with close_forum_topic and delete_forum_topic
functions we've used many times
- Only after I pushed back did Claude actually check the code and find the capability
The problem:
Claude is defaulting to "I can't do that" before investigating. It's treating requests as impossible
rather than checking available tools, existing code, and prior context. This is the opposite of how an
agentic coding assistant should behave.
What I expect:
When asked to do something, Claude should:
- Search the codebase for relevant functions
- Check what APIs/tools are available
- Try approaches before claiming something is impossible
Instead I'm getting reflexive refusals that waste time and require me to argue with the assistant to get
it to do its job.
Environment Info
- Platform: darwin
- Terminal: tmux
- Version: 2.1.7
- Feedback ID: 98a85f39-960f-4fbf-8570-7e2bd5a7b901
Errors
[{"error":"Error: NON-FATAL: Lock acquisition failed for /Users/greg/.local/share/claude/versions/2.1.7 (expected in multi-process scenarios)\n at ALR (/$bunfs/root/claude:3168:2157)\n at eFA (/$bunfs/root/claude:3168:1268)\n at processTicksAndRejections (native:7:39)","timestamp":"2026-01-14T03:15:09.299Z"}]This issue has 5 comments on GitHub. Read the full discussion on GitHub ↗