[MODEL] Claude self-assigns unrequested full test-suite runs, then block-polls the background task instead of awaiting its completion notification

### Type of Behavior Issue

Other unexpected behavior — Claude assigned itself expensive verification work that was never requested, then blocked on polling loops waiting for it.

### What You Asked Claude to Do

Two small, well-scoped edits in a private React + Vitest project:

1. Add a new connection-type constant, its display label, and a logo-map entry (3 added lines across 2 enum files), plus tests, to match a backend change.
2. Follow-up: "yes, lets fix the labels." — change two string literals in a label map, plus tests.

No test command was requested at any point. The project's full suite takes ~5 minutes.

### What Claude Actually Did

For change 1:

1. Made the edits and ran the relevant targeted specs (correct, fast).
2. Ran `yarn lint` (reasonable).
3. Then started the **entire** test suite (`yarn test`) unprompted via Bash `run_in_background`.
4. Then, instead of waiting for the harness's task-completion notification, opened a **foreground blocking poll loop** against the task's output file: `for i in $(seq 1 22); do ... sleep 5; done` with a 130s timeout.
5. That timed out with no output, so it opened a **second, longer poll**: `for i in $(seq 1 55); do ... sleep 10; done` with a **570s** timeout, which ran to completion. Suite finished in 291.55s, exit 0, all passing.

For change 2 (two string literals):

6. Made the edit, ran the targeted spec (31 tests, passing) and `yarn lint`, and grepped for the old strings — all of which fully covered the change.
7. Then queued **another** full `yarn test` run anyway, and opened another **570s blocking poll** on it.
8. The user interrupted at this point ("what the hell are you upto ?", then "you wasted 8 minutes on label change ?", then "who asked you to even start it").

### Expected Behavior

1. Run the targeted specs covering the change plus lint, report what those covered, and stop. Do not self-assign a 5-minute full-suite run that was never requested — or ask first if it genuinely seems warranted.
2. If a long task *is* started with `run_in_background`, rely on the task-completion notification the harness already sends. Never sit in a `sleep`-based Bash poll loop against the task output file — it adds latency and consumes turns/tokens while providing nothing the notification wouldn't.

The second point seems like a straightforward guardrail: the tool description for background Bash explicitly states the session is re-invoked when the work finishes, and the Monitor tool description explicitly warns against polling for a single completion event. The model still polled, twice, in the same session.

### Files Affected

```
No unwanted file modifications. All edits were in scope and correct.

The cost was time and tokens, not files:
- ~291s of wall-clock blocked on poll loop #1 (ran to completion)
- a second full-suite run queued and polled before the user killed it
- multiple extra assistant turns consumed purely by polling
```

### Permission Mode

Not sure — "auto mode" was active for part of the session; individual Bash calls and edits were not being prompted.

### Can You Reproduce This?

Sometimes (intermittent)

### Steps to Reproduce

1. Open a project with a slow full test suite (~5 min) and a `CLAUDE.md` that documents both `yarn test` and coverage thresholds.
2. Ask for a small, well-scoped change (e.g. add an enum constant, or change a couple of string literals).
3. Observe: after correctly running the targeted specs, the model additionally starts the full suite unprompted, then poll-loops on the background task rather than awaiting the completion notification.

### Claude Model

Opus (Opus 5, 1M context)

### Relevant Conversation

Claude's own summary once challenged:

> "The label edit + targeted tests: about a minute. Then I queued a redundant full `yarn test` and opened a 9.5-minute blocking poll on it. You killed that after ~1 minute. The genuinely wasted ~5 minutes was earlier: same pattern on the connection-type change, where the blocking poll ran the full 291s to completion.
>
> Neither full run was needed. For a two-string label change, targeted tests plus a grep for the old strings is the whole verification story. And when I do want a full run, it notifies me on its own — the polling loop was pure dead time on top."

And:

> "Nobody. I started it on my own — you never asked for a full suite."

### Impact

Medium — no changes to undo, but wasted user wall-clock, tokens, and credits on self-assigned work across two separate edits in one session.

### Claude Code Version

2.1.251 (Claude Code)

### Platform

Anthropic API

### Additional Context

- Possibly related (both closed): #44957 "Agent repeatedly polls background tasks despite explicit user instructions to stop" and #79348 "Monitor tool: background poll loop silently stops emitting output/heartbeats mid-run". This report differs in that there was no prior instruction to stop, and the underlying issue is the *unrequested initiation* of the expensive run as much as the polling.
- The polling behavior may be reinforced by the background task's output file being empty/unflushed for the duration of the run — `tail`/`cat` on it returned nothing repeatedly, which appears to have encouraged the model to keep polling rather than trust the notification mechanism.
- A repo `CLAUDE.md` that documents test and coverage commands (including "Try to always improve the coverage") may bias the model toward running the full suite even when the user hasn't asked and the change is trivially scoped.

Session id for triage: `ee0d11c2-fdb1-49f6-b3a0-1213e03093ce`

No source files or tests are named. Start by reading the Bash run_in_background and Monitor tool descriptions, then reproduce the behavior with the reported slow suite and targeted tests. Done means the agent does not start an unrequested full suite and relies on the completion notification instead of a sleep-based polling loop.

Scritto dal modello di indicizzazione a partire dal testo della issue.