Resume auto-fires armed background shells//loop wakeups/watches before any input — no way to disable or confirm

Problem

Resuming a session (claude -r <id> / claude --continue, or /resume) immediately re-arms and fires anything the session left running — background shells, /loop wakeups, artifact watches — before the user types anything. There is no setting to prevent this and no confirmation step.

This interacts badly with the prompt cache. If the session is older than the cache TTL, the resume re-sends the entire transcript uncached (a cache write at the 1-hour-TTL 2× premium instead of a ~0.1× read), and the auto-fired background work triggers those full-price requests on load. In one real case this combination silently consumed a full quota window with zero user input: the user resumed an old session that contained background shells, and requests started firing on their own.

The two halves are each reasonable in isolation — resuming restores session state, and background tasks resume where they left off — but together they mean "reopening a session to look at it" can be one of the most expensive single actions in the product, with no warning and no opt-out.

Suggested fixes (any of these would resolve it)

• [ ] Confirm before re-arming: on resume, list the session's armed background shells / loop wakeups / watches and ask before firing them (interactive sessions only; --print could keep current behavior)
• [ ] A flag and/or setting to resume with background work disarmed, e.g. claude -r <id> --no-autofire or "resume": {"autofireBackgroundTasks": false}
• [ ] At minimum, document that resume auto-fires armed background work immediately, so users know an idle-looking session can spend on load

Environment

• Claude Code 2.1.251, Linux (WSL2)
• Reproduces with: start a background shell or /loop in a session → exit → wait past the cache TTL → claude -r <session-id> → observe requests fire with cache_read_input_tokens: 0 before any prompt is typed