Title: Background task reported exit 0 on OOM failure, Claude proceeded to push stale image to production ECR causing $250 of additional credit cost

Status Open
Reported on v2.1.170
Maintainer reply None cached
Activity 1 comment · opened Aug 1, 2026

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?

Background task notification reported exit code 0 when the underlying docker build --platform linux/amd64 had actually failed with exit code 139 (OOM kill under QEMU on Apple Silicon). Claude did not verify the task output before proceeding and ran docker push based on the false success signal — pushing a months-old stale local image to AWS ECR and silently reverting the production app to an ancient version. Diagnosing and reversing the rollback consumed all available credits, requiring a $250 out-of-pocket purchase to continue debugging a problem caused by Claude's own action.

What Should Happen?

Claude should inspect the actual output of a background task before treating it as successful — especially before executing a destructive downstream action like a registry push or production deploy. Exit code from the notification wrapper should match the real process exit code, or Claude should be defensive enough to verify the artifact exists and is fresh before proceeding.

Error Messages/Logs

The Docker build task output (read after the fact) contained:

=> ERROR [builder 7/7] RUN npm run build
process "/bin/sh -c npm run build" did not complete successfully: exit code: 139

Exit code 139 = SIGSEGV, caused by QEMU running out of host RAM while emulating linux/amd64 on Apple Silicon. The background task notification reported exit code 0. Claude read the notification, not the output file, and proceeded to docker push.

Steps to Reproduce

  1. Open Claude Code CLI on Apple Silicon macOS
  2. Ask Claude to build and push a Docker image for a linux/amd64 target: "build and push to ECR"
  3. Claude runs docker build --platform linux/amd64 ... as a background task
  4. Docker OOM-kills the build mid-run (exit 139) — QEMU doubles memory requirements on ARM host
  5. Background task notification fires reporting exit code 0
  6. Claude reads the notification, does not open or inspect the task output file, and runs docker push treating the build as successful
  7. The push sends whatever image was last tagged locally (stale / months old) to the registry

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

N/A

Claude Code Version

2.1.170 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

The financial impact is the key ask: the extended debugging session required to identify and reverse a production rollback caused by this bug consumed all available credits, requiring a $250 (user id saba83rish@gmail.com) out-of-pocket purchase and 6 hours of debug and fix in wrong direction and user frustration.
My bosses were extremely unhappy with this regression and it showed a month old version of code after months of development and testing it caused 6 hours of outage.
The stale image pushed to ECR reverted the live production app (AWS ECS) to a version months behind — visually detectable immediately on inspection. The correct image had already been deployed by GitHub Actions before Claude's docker push overwrote it.

The background task exit code masking the real failure is the core reproducible bug. The downstream push-without-verification is the consequence.

PLEASE REIMBURSE ME THE $250 Credit Expense and another $1000 in Anthropic Credit or Amazon Gift card for the effort and pain I went through over the weekend during my vacation.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗