[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
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)
- 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).
- It ran several tile rebuilds this way during the session — each a fresh
create+delete cycle, i.e. potentially multiple billed hours.
- 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.
- 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.
- The user interrupted; only then did the agent read
build-vm.shand 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
- Did NOT read the documented deployment rules before acting, despite a mandatory
rule to do so.
- Chose a convenient existing script (
update-maps-cloud.sh, create+delete) over
the correct, rule-compliant tool (build-vm.sh, persistent VM).
- 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
- 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).
- 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.
- 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.
- 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_
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗