[FEATURE] Add autoResume config option to automatically continue last session in a directory
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:
- SessionEnd hooks + shell aliases — Writing the session ID to a
.claude_sessionfile 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)
- Shell aliases — Aliasing
claudetoclaude -cglobally. Too aggressive — sometimes you want a fresh session.
- 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
- I'm working on an iOS app with a Swift codebase
- I have a long Claude Code session where we've established context about the architecture, discussed a bug, and started implementing a fix
- I close the terminal to grab lunch, or my tmux session gets interrupted
- I come back,
cdinto the project, and typeclaude - Current behavior: Fresh session, all context lost. I have to remember
claude -c - Expected behavior with
autoResume: true: Session picks up exactly where I left off. If I want a fresh start, I can either runclaude --newfrom the terminal or just runclaudeand type/newinside the session
Additional Context
- This is a low-risk, high-quality-of-life change — it's essentially sugar over existing
--continuebehavior - Project-level config makes sense as the default scope since session continuity is project-specific
- Similar concept to how
git configworks with per-repo and global settings - The override flag (
--newor 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
--continuelogic - #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.
This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗