Cloud tasks from deleted repo re-provision containers and show 'Session resumed' without user action

Open 💬 0 comments Opened Jul 12, 2026 by rokr-ch

Environment

Claude Code on the web (claude.ai/code), German UI. Personal GitHub account; the repo referenced by the affected tasks was deleted 2026-04-12 (verified via GitHub security log).

What happened

Old cloud tasks created in Feb/Mar 2026 for a prototype repo (repo deleted months ago, Claude GitHub App uninstalled, app authorization revoked) suddenly showed new activity on two consecutive days (2026-07-11/12):

  • Task timeline shows: old completed transcript → «Ein API-Fehler ist aufgetreten» → «Cloud-Container einrichten ✓» → «Repository geklont ✗» ("The git_repository source could not be found…") → «Sitzung fortgesetzt»
  • The user did not open or resume these tasks. His session list filter shows only the last 7 days — the tasks surfaced precisely because they received new activity.
  • It happened to two different stale tasks of the same deleted repo on two different days, shortly after the web UI changed to the new sidebar with repo-grouped tasks/sessions — which suggests a migration/re-indexing pass re-provisions containers of stale tasks.
  • GitHub side verified clean: security log shows zero repo events after the repo deletion; the GitHub App shows "last used" timestamps matching the failed clone attempts.

Looks related to #63720 / #63714 (container resume loop) and #55990 (autonomous resume).

Why this matters

For non-developer business users this is indistinguishable from a compromise: a task they never touched shows fresh provisioning steps and "Session resumed", listing months-old commit/push summaries. It cost a support-heavy investigation (security log export, app installation audit) to prove nothing had happened.

Expected

Stale/completed cloud tasks should never re-provision containers or emit new session events without an explicit user action. If a platform migration must touch them, it should not surface as user-visible "activity" (and ideally tasks whose source repo returns 404 should be flagged as orphaned instead of resumed).

Ask

  • Confirm whether a July 2026 migration/re-indexing re-provisions stale cloud task containers.
  • Treat orphaned tasks (repo deleted) as terminal: no auto-resume, no container setup.

View original on GitHub ↗