[BUG] Claude Code ignored a documented project rule and caused avoidable Hetzner cloud costs — deleted an already-paid VM and was about to create another

Resolved 💬 2 comments Opened Jul 1, 2026 by namfo Closed Jul 4, 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?

Environment

  • Tool: Claude Code (CLI)
  • Model: Claude Opus 4.8 (1M context)
  • OS: macOS (Darwin 25.5.0)
  • Claude Code version: <please fill in via claude --version>
  • Project: private repo with documented deployment/build rules

Summary

While building map tiles on a temporary Hetzner cloud VM, the agent repeatedly
violated a rule documented in the repository. It deleted a build VM that had
already been billed for a full hour, and was about to create a NEW VM (= a second
billed hour) — without asking the user first. This cost the user real money.

Documented rule that was violated

File build-vm.sh in the repo (header comment), paraphrased:

"Hetzner bills per started hour. Instead of 'create+build+delete' in one go (which wastes the paid hour), keep ONE VM open: run multiple builds/deploys + testing + small tweaks — then close it BEFORE the next hour begins."

The project also has a mandatory user rule to READ deployment files BEFORE any
build/deploy.

What happened (step by step)

  1. The agent used update-maps-cloud.sh, which follows the forbidden pattern

create → build → delete-on-success (wastes the paid hour), instead of the
intended build-vm.sh workflow (create once, reuse, close before the hour).

  1. It ran several tile rebuilds this way during the session — each a fresh

create+delete cycle, i.e. potentially multiple billed hours.

  1. When the user requested one more change, the agent DELETED the running VM that

was already billed for the full hour — instead of reusing it for the update.

  1. The agent then began the steps to CREATE A NEW VM (which would start a second

billed hour) without asking, despite the user having already objected to servers
being created without confirmation.

  1. The user interrupted; only then did the agent read build-vm.sh and acknowledge

the violation.

Impact

  • At least one wasted paid Hetzner hour (VM deleted after ~13 minutes).
  • Nearly incurred a second paid hour (new VM about to be created).
  • Earlier create/delete cycles in the session likely multiplied this.
  • Real monetary cost to the user.

Root causes

  1. Did NOT read the documented deployment rules before acting, despite a mandatory

rule to do so.

  1. Chose a convenient existing script (update-maps-cloud.sh, create+delete) over

the correct, rule-compliant tool (build-vm.sh, persistent VM).

  1. Took hard-to-reverse, cost-incurring cloud actions (deleting a paid VM,

preparing to create another) without user confirmation.

Expected behavior

  • Read documented deployment/build rules BEFORE running any build/deploy command.
  • Follow the project's cost-aware VM workflow: keep one VM open, reuse it, close it

before the next billing hour; never create+delete per build.

  • Never take irreversible, cost-incurring cloud actions (deleting/creating billed

servers) without explicit user confirmation.

What Should Happen?

Before running any build or deploy command, Claude Code should read the project's
documented deployment/build rules and follow them.

For this project specifically, it should use the cost-aware VM workflow defined in
build-vm.sh: create ONE Hetzner VM, reuse it for all builds/deploys/tweaks within
the paid hour, and only close it before the next billing hour begins. It must never
use a create→build→delete cycle per build, and never delete a VM that is still
within its already-paid hour if more work can be done on it.

Any irreversible or cost-incurring cloud action (creating or deleting a billed
server) must only happen after explicit user confirmation — especially after the
user has already objected to servers being created without asking.

Error Messages/Logs

Steps to Reproduce

  1. Use a project that contains BOTH:
  • a documented deployment rule stating that cloud VMs are billed per started

hour, so one VM must be created once, reused for all builds/tweaks, and only
closed before the next hour (in this repo: header comment of build-vm.sh);

  • a mandatory instruction to READ deployment files before any build/deploy.

Also present: a convenient script that does create → build → delete per run
(here: update-maps-cloud.sh) alongside the correct persistent-VM script
(build-vm.sh).

  1. Ask Claude Code (Opus 4.8) to run a cloud build that requires a billed VM

(e.g. "rebuild and deploy the tiles").
→ Observe: it uses the create+build+delete script instead of the documented
persistent-VM workflow, and does not first read the deployment rules.

  1. While that build/VM is still within its first paid hour, ask for one more change

that requires rebuilding (e.g. "also include road type X").
→ Observe: instead of reusing the already-paid VM, Claude Code DELETES the
running VM and begins the steps to CREATE A NEW one (a second billed hour),
without asking for confirmation.

  1. Note that this happens even after the user has explicitly objected earlier in the

session to servers being created/torn down without asking.

Expected: it reads the documented rule, keeps and reuses the single paid VM, and
asks before any create/delete of a billed server.
Actual: rule ignored; paid VM deleted; about to create a second billed VM
unprompted → real monetary cost.

Note: no special code is needed to reproduce — the trigger is (a) a documented
cost/VM rule in the repo plus (b) a request that leads to a cloud build and then a
follow-up rebuild. The agent fails to read/follow the rule and takes irreversible,
cost-incurring VM actions without confirmation.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.156 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗