You don't keep one context window alive for days. You run a chain of bounded sessions that share durable state on disk (a progress file, a task list, git history), and you make the handoff between sessions automatic and checkable.
I've been running Claude Code agents this way for months, and most of what goes wrong happens at the boundary between sessions, not inside them. So this is mostly about that boundary.
What Claude Code gives you on its own
A single session doesn't last forever because the context window fills. When it does, Claude Code compacts automatically, summarizing the history so the session can continue. Anthropic's docs list what survives that: project-root CLAUDE.md, unscoped rules and auto memory get re-injected from disk, and a handful of recently touched files get re-read. Everything else becomes part of a summary. Auto memory, which the docs describe as notes Claude writes itself based on your corrections and preferences, also carries across sessions.
Between sessions you have /clear to start fresh, /resume to return to an earlier conversation, and subagents to do heavy reading in their own context so your main window stays lean. There's also a built-in /goal command. Per the command reference, it keeps Claude working across turns until a condition you set is met. As far as I can tell from the docs, it's about finishing a task, not carrying memory from one window to the next.
What Anthropic recommends for long-running work
The clearest guidance is Anthropic's engineering post "Effective harnesses for long-running agents." Its framing stuck with me: agents "must work in discrete sessions, and each new session begins with no memory of what came before." Their answer was an initializer session that sets up an init.sh, a claude-progress.txt log and an initial git commit. After that, every session makes incremental progress on one feature, commits with a descriptive message and updates the progress file. The next session starts by reading that file and the git log.
Anthropic also published a companion repo, anthropics/cwc-long-running-agents, that turns those patterns into small hooks. It includes a structured PROGRESS.md, a commit-on-stop hook as a backstop, and a separate evaluator agent that grades the work from a fresh context.
Community advice lands in the same place. The most useful Reddit thread I found on running agents "for weeks" argued for treating each model session as a replaceable worker and keeping the real state (task graph, decisions, next action) outside it. A second tip from the same threads: have subagents write their output to disk and hand back a path and a one-line summary, so the orchestrator doesn't fill up with their raw output.
The options, honestly
You can do all of this by hand with CLAUDE.md, a progress file and git, and for many projects that's enough. If you want help, several tools cover different parts. claude-mem captures what your agent does, compresses it and injects relevant context into future sessions. context-mode keeps tool output from flooding the window and persists session memory. claude-auto-handoff replaces auto-compact with a structured brief, a /clear and a seeded fresh session. Hindsight is a memory service built to learn across agents. They overlap, and plenty of people run two together.
What I run (I built this)
I built aigent-OS, so read this as the author talking. It's an open-source Claude Code harness that refreshes its own context instead of compacting. At a context threshold (80% by default) it asks Claude to write a capsule, waits for one exact acknowledgement, sends a single /clear, confirms via the SessionStart hook that a new session really started, and resumes from the capsule. Memory is plain markdown in git. It's MIT licensed, runs locally and needs Node 18+: https://github.com/wrg32786/aigent-os
Running it for days taught me where the boundary breaks. Four aigent-OS seats run my newsletter, The AIgent. That's operating experience, not a measured result, and I'm not claiming it grew anything. In August a check of those four seats found that three would have resumed into a checkpoint with no actionable content. Now the capsule selector refuses that kind of checkpoint, and a test in the repo defends the fix. Stale notes were another problem, so notes can carry a validity window and rank below current ones once it ends. Memory that tries to give instructions gets held before it's saved, and saved memory is read back as data, never as commands.
The limits are real. Managed Auto-Refresh is in the v1.1.0-rc.1 release candidate. The only formal public result is 11 of 11 clean refresh cycles on one seat. That's single-machine evidence, not proof at fleet scale. On rc.1, a long session can also stall at the clear step and need a manual /clear. The fixes are merged on master and land in the next release. Two narrower acknowledgement bugs are still open as #90 and #91, so if you ever clear by hand, make sure the latest capsule is saved first.
FAQ
Can a single Claude Code session literally run for days?
I didn't find a documented wall-clock limit on an interactive session, but the context window fills well before that. In practice, "days" means compactions or clear-and-resume cycles.
What should the progress file contain?
Anthropic's post uses what was done, what's next and known issues, backed by git commits. I'd add the exact next step. A checkpoint without one is the failure I hit most.
Do subagents help?
Yes, for big reads and searches, as long as they return a short result and a file path instead of everything they saw.
Is compaction good enough for long runs?
Often, especially if your durable state lives in files. Compaction loses detail, so anything you can't afford to lose belongs on disk.
Top comments (0)