[FEATURE] Cloud sessions: keep the container warm for a grace window after activity (30-60s resume triggered by even a 2-minute pause)

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

I use Claude Code on the web heavily (cloud sessions, accessed through the Windows desktop app and claude.ai/code, also from iPad/iPhone). The cloud container suspends after a very short period of inactivity — short enough that even a ~2-minute pause while I compose my next message triggers it. My next message then waits 30-60 seconds on "resuming session" before Claude begins responding.

The result is that in an ordinary interactive conversation, nearly every message pays the resume penalty: a 2-minute human pause costs a ~1-minute machine delay. Over a working session this adds up to a large share of total wait time. We measured the session's actual model and tool round-trips at ~3 seconds each, so the resume thaw dominates perceived latency for conversational use.

I checked the docs (claude-code-on-the-web, cloud-environments): suspension after inactivity is documented, but the timeout length is not, and no setting, environment option, or flag controls it today.

Proposed Solution

Keep the session's container warm for a grace window after the last activity — even 5 minutes would eliminate the penalty for normal conversational pacing (a human reading a reply and typing the next message). Suspension after genuinely long idle periods can stay exactly as it is; the request is only that a brief between-turns pause not trigger it.

Alternative Solutions

Alternatively (or additionally): expose the idle timeout as a per-environment or per-session setting, so users can choose the latency/cost tradeoff themselves.

Workarounds tried: none exist today. The docs document suspension but not the timeout length, and no setting, environment option, or flag controls it. Issue #32050 indicates even long-running background tasks don't prevent the idle timeout, so there is no way to hold the container open from inside a session either.

Priority

High - Significant impact on productivity

Feature Category

Performance and speed

Use Case Example

Example scenario:

1. I ask Claude to make a change; it works for a couple of minutes and replies.
2. I read the reply and type my next message — this routinely takes me 2-5 minutes (I proofread longer prompts).
3. By the time I press Enter, the container has already suspended, and my message waits 30-60 seconds on "resuming session" before Claude even starts.
4. This repeats on nearly every turn of the conversation.
5. With a ~5-minute grace window, step 3's delay would disappear for normal conversational pacing, and the measured ~3-second model round-trips would be what I actually experience.

Additional Context

Measurements from a long-running cloud session (reading its own transcript): model round-trip median ~3.1 s, tool execution median ~0 s — the container itself is fast; the resume thaw is the dominant wait for interactive use.

Related but distinct existing issues: #32050 (closed as stale — idle timeout disconnects during long-running background tasks; confirms the timeout ignores in-session activity) and #66115 (auto-compact on idle timeout to prevent cache-expiry cost — a different mitigation of the same idle boundary).

Cloud Claude Code is excellent — this is the one rough edge that most affects the day-to-day feel of working in it.