[BUG] --resume fails with error_during_execution when session was auto-archived during idle period #39178

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

When using claude --resume <session_id> to continue a session that was actively used minutes earlier, the CLI returns error_during_execution (rc=1) with 0 turns and $0.00 cost. The session JSONL file has been auto-archived (moved from ~/.claude/projects/<project>/ to ~/.claude/projects-archive/) during the idle period between runs, and --resume does not check the archive directory.

This is distinct from #32651 (Remote Control web/mobile archival) — this affects the CLI --resume flag used by programmatic consumers.

Timeline of the Failure

The session was auto-archived just 29 minutes after its last successful use.

Evidence

Session file location after archival:

# Active project dir — session JSONL is GONE (only subdirs remain):
~/.claude/projects/-home-nathan-lba-apps-wp-plugins-wp-nav-main/0a1e105b.../
├── subagents/
└── tool-results/

# Session JSONL moved to archive:
~/.claude/projects-archive/0a1e105b-81c0-496f-95c2-e69e445f9d0c.jsonl
  Size: 5.7M (1953 lines)
  Modified: 2026-03-26 14:01 (last successful run)
  Changed:  2026-03-26 14:30 (when file was moved to archive)

CLI output (stream-json):

{"type":"result","subtype":"error_during_execution","session_id":"185254b6-...","is_error":true,"num_turns":0,"total_cost_usd":0}

Note: the session_id in the error result (185254b6) is a new session ID, not the one that was requested via --resume (0a1e105b). The CLI created a new session just to report the error.

What Should Happen?

One or more of:

1. --resume should check the archive directory as a fallback when the session isn't found in the active project dir
2. Sessions that are being actively resumed should not be auto-archived — the archival threshold should consider last-access time, not just idle since last write
3. The error result should include a structured reason (e.g., "error_code": "session_archived") so programmatic consumers can distinguish archival from corruption, disk full (ENOSPC), etc.
4. At minimum, the errors array should say "session archived" rather than silently failing with a generic error_during_execution

Context

This affects programmatic consumers of --resume that maintain long-lived sessions across multiple invocations — e.g., Untether (Telegram bridge for Claude Code). In this usage pattern, a session is resumed many times over hours/days via claude --resume <id>, with idle gaps between runs. This is different from interactive CLI usage where users start fresh sessions more often.

The session in question was 5.7MB / 1953 lines / 138 turns accumulated over 2 days — large but functional. Other active sessions of similar size (~5MB) in other projects were NOT archived, suggesting the archival threshold is inconsistent.

Steps to Reproduce

1. Start a Claude Code session and note the session ID
2. Resume it several times over a period to build up history (or use a large session)
3. Wait ~30 minutes with no CLI process running
4. Run claude --resume <session_id>
5. Observe error_during_execution with rc=1

Exact idle threshold is unclear — in our case it was ~29 minutes. #32651 reports ~10-15 minutes for Remote Control archival.

Claude Code Version

2.1.84 (Claude Code)

Platform

Anthropic API (Max subscription)

Operating System

Ubuntu/Debian Linux (Hetzner VPS)

Terminal/Shell

zsh (headless, invoked programmatically via subprocess)