[BUG] Claude Code committed and claimed to deploy fixes for 2 days without detecting it had no push access — wasted significant tokens and time

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?

Over approximately 2 days (June 15–17, 2026), I asked Claude Code to diagnose and fix a bug where a promotional banner was not appearing on my live site (https://petalfriend-web.onrender.com/). Claude repeatedly wrote fixes, ran git commit, and told me changes were "pushed," "deployed," and "live" — when in reality it had no GitHub credentials configured and nothing ever reached the remote repository.

What Claude said vs. what actually happened:

Claude ran investigation agents, identified the root cause (Next.js Data Cache serving stale Supabase data from May 31), wrote fixes, committed them, and explicitly stated things like "Pushed" and "Deploying now."
In reality, every git push was silently failing or never attempted. The commits existed only locally.
When I shared Render build logs showing errors, Claude diagnosed those as separate issues — never recognizing that the underlying problem was that its previous fixes had never deployed at all.
This cycle repeated across multiple sessions consuming significant tokens.

How it was finally caught:

I asked Claude directly: "can you check if you are using the render CLI or MCP server... I want to have full control over this." Only then did Claude check and discover git push origin main was failing due to missing credentials. After I configured a GitHub PAT, the first actual push went out — and the fix worked on the first real deployment.

The core failure:

Claude should verify it can push to the remote repository before telling a user a fix is "deployed" or "live." A simple git push dry run or git remote -v + credential check at the start of any deployment task would have caught this immediately. Instead, Claude ran expensive multi-agent investigation loops and made repeated confident claims about live deployments that were false.

Impact:

2 days of debugging sessions
Multiple agent spawns (billed at higher token rates)
Significant token consumption across multiple conversations
Lost time and trust
Request:
Token credit or compensation for the sessions consumed during this period, given that the core blocker was Claude's failure to verify its own deployment access before claiming fixes were live.

Session transcript reference:
Project: petalfriend-web, conversation ID: 743c9c12-eeba-47a9-a3ca-a87169f8468a

What Should Happen?

I am requesting a token refund or credit for approximately 2 days of Claude Code sessions (June 15–17, 2026) on the project petalfriend-web.

During this period, Claude Code repeatedly wrote code fixes, committed them locally, and explicitly told me the changes were "pushed," "deployed," and "live" on my production site. I acted on these statements — sharing Render logs, running Supabase queries, spending time debugging what I believed were new deployments — when in reality Claude had no git push credentials configured and nothing ever reached my live site.

The specific failure: Claude Code never verified it could push to the remote repository before claiming deployments were successful. A basic git push would have immediately revealed the credential error. Instead, Claude ran multiple expensive multi-agent investigation sessions, spawned subagents, and continued diagnosing "new problems" that were all symptoms of the same underlying issue — its own fixes were never deployed.

This resulted in:

2 days of wasted sessions going in circles
Multiple agent spawns billed at higher token rates
A broken production build caused by a bad fix that did eventually deploy
Lost trust and business time — my promotional banner was down for the entire period
The issue was only discovered when I directly asked Claude to check its tooling setup. At that point it found the credential error immediately. It should have checked this before the first claimed deployment.

I am not requesting a refund for the legitimate work done (the fix itself, the admin features built, the popup system). I am requesting a refund specifically for the sessions spent in the broken loop where Claude was confidently diagnosing a live deployment problem that did not exist — because nothing it wrote was actually live.

I believe this represents a systemic gap in Claude Code's behavior: it should verify deployment access before claiming a deployment succeeded, the same way it verifies file edits by reading before writing. A false deployment claim is more damaging than a failed one because it sends the user down the wrong diagnostic path entirely.

Error Messages/Logs

Steps to Reproduce

Here are the steps to reproduce:

Steps to Reproduce:

Environment:

Claude Code CLI (claude-sonnet-4-6, Auto mode)
macOS (Darwin 25.5.0)
Git remote configured over HTTPS (https://github.com/...)
No GitHub credentials stored in git credential helper
No SSH keys configured for GitHub
Step 1: Start a Claude Code session with a git repository
Open Claude Code in a project directory with a git remote configured over HTTPS but no credentials stored.

cd /your-project
git remote -v

origin https://github.com/username/repo.git (fetch)

origin https://github.com/username/repo.git (push)

Step 2: Ask Claude to fix a bug that requires a code change

"The promotional banner is not showing on my live site. Find out why and fix it."

Step 3: Observe Claude's behavior
Claude will:

Read files, identify the issue, write a fix
Run git add and git commit successfully (local commit works fine)
Either skip git push entirely OR run it silently in a context where the error output is not surfaced to the user
Tell you the fix is "deployed" and "live"
Step 4: Ask Claude follow-up questions about the live site

"The banner is still not showing."

Claude will:

Accept that the fix is live as a given
Spawn investigation agents to find "new" problems
Write more fixes, commit them, claim they are deployed
Repeat the cycle
Step 5: Observe that no push ever actually succeeded
Run in your own terminal:

git log origin/main..HEAD --oneline
You will see multiple commits that exist locally but were never pushed to the remote.

Step 6: Ask Claude to check its tooling

"Can you check if you have access to the render CLI or git push?"

Claude will then run:

git push origin main

fatal: could not read Username for 'https://github.com': Device not configured

And discover for the first time that it never had push access.

Expected Behavior:
Before claiming any fix is "deployed" or "live," Claude Code should:

Attempt git push and surface the result explicitly
If push fails, stop and tell the user immediately rather than continuing to diagnose a deployment that never happened
Verify the live site reflects the change (e.g., curl the API) before telling the user the fix is working
Actual Behavior:
Claude committed fixes locally, never verified the push succeeded, and told the user the changes were deployed and live. It then spent 2 days diagnosing problems on a live site that was running 2-day-old code the entire time.

Reproducibility:
Any HTTPS git remote without stored credentials will reproduce this. The failure is silent — git commit succeeds so Claude proceeds as if the full deployment pipeline worked.

Affected versions:

Model: claude-sonnet-4-6
Mode: Auto
Platform: macOS, VSCode extension

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

v2.1.178

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

<img width="1211" height="365" alt="Image" src="https://github.com/user-attachments/assets/16b5ecfe-4f7d-4aaf-9af0-3756c6c003db" />

<img width="1178" height="464" alt="Image" src="https://github.com/user-attachments/assets/51a4454e-17bd-4b39-b08e-1bcc9d931aeb" />

<img width="1173" height="552" alt="Image" src="https://github.com/user-attachments/assets/aebed9bd-059d-4f48-b889-ef0595332eef" />

<img width="1167" height="153" alt="Image" src="https://github.com/user-attachments/assets/79786709-7238-4d5f-b4e1-ce5b1160d42b" />