[FEATURE] Add autoResume config option to automatically continue last session in a directory

Resolved 💬 4 comments Opened Mar 10, 2026 by Demircivi Closed Apr 8, 2026

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

When working on a project, I frequently close my terminal or exit Claude Code and want to pick up where I left off. Every time, I have to remember to pass --continue or --resume manually. This adds friction to the workflow, especially when juggling multiple projects across different terminal tabs/tmux panes.

The core issue is that session continuity should be opt-in at the config level, not something you have to remember every single time you launch claude. Forgetting to pass the flag means starting a fresh session and losing the context you built up.

Proposed Solution

Add an autoResume configuration option that can be set at the project or global level:

claude config set autoResume true
claude config set autoResume true --global

When enabled, claude (with no arguments) would automatically continue the most recent session in the current directory — equivalent to running claude --continue. If there's no previous session, it starts a fresh one as usual.

Passing an explicit flag like --new or a prompt argument would override this behavior and start a fresh session.

The setting could live in .claude/settings.json alongside other config options:

{
  "autoResume": true
}

Alternative Solutions

The community has built several workarounds for this:

  1. SessionEnd hooks + shell aliases — Writing the session ID to a .claude_session file on exit, then reading it back from a shell function. Works but requires manual hook setup and shell config. (ref: erikzaadi.com/2026/02/15/auto-resume-claude-code-sessions)
  1. Shell aliases — Aliasing claude to claude -c globally. Too aggressive — sometimes you want a fresh session.
  1. Third-party scripts like claude-auto-resume — A shell script that wraps Claude CLI with auto-resume logic. Works but adds an external dependency for what should be a native feature.

The fact that multiple community members have independently built workarounds for this suggests strong demand for native support.

Priority

Low - Nice to have

Feature Category

Configuration and settings

Use Case Example

  1. I'm working on an iOS app with a Swift codebase
  2. I have a long Claude Code session where we've established context about the architecture, discussed a bug, and started implementing a fix
  3. I close the terminal to grab lunch, or my tmux session gets interrupted
  4. I come back, cd into the project, and type claude
  5. Current behavior: Fresh session, all context lost. I have to remember claude -c
  6. Expected behavior with autoResume: true: Session picks up exactly where I left off. If I want a fresh start, I can either run claude --new from the terminal or just run claude and type /new inside the session

Additional Context

  • This is a low-risk, high-quality-of-life change — it's essentially sugar over existing --continue behavior
  • Project-level config makes sense as the default scope since session continuity is project-specific
  • Similar concept to how git config works with per-repo and global settings
  • The override flag (--new or similar) is important so users aren't locked into always resuming

Related issues (not duplicates):

  • #6254 — "auto resume" but focused on rate-limit/overload recovery, not startup behavior
  • #29495 — Proposes saving resume command to a file on exit. Similar motivation but different approach: file-based persistence vs. a native config flag that wraps existing --continue logic
  • #18980 — Auto-continue after rate limit reset, different scope entirely

This feature is distinct because it targets the startup flow — making claude (no flags) resume by default when configured — rather than recovering from interruptions or persisting session IDs to disk.

I'm happy to implement this and open a PR — just wanted to check first if this is something the team would want natively, or if there's a reason it's been intentionally left out.

View original on GitHub ↗

This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗