How to keep a Claude Code agent running for days without losing context

Running Claude Code agents for extended periods can be challenging, but there are strategies to maintain context across multiple sessions. The key is to break the work into discrete sessions, each starting with no memory of previous sessions. To achieve this, set up an initializer session that creates an init.sh file, a claude-progress.txt log, and an initial git commit.

Subsequent sessions should focus on incremental progress on a single feature, committing changes with descriptive messages and updating the progress file. Anthropic also recommends using a companion repository with structured PROGRESS.md, a commit-on-stop hook, and a separate evaluator agent that grades the work from a fresh context.

Community advice suggests treating each model session as a replaceable worker and keeping the real state outside the session. This includes maintaining a task graph, decisions, and the next action in an external location. Subagents can write their output to disk and return a path and a one-line summary, reducing the amount of raw output that needs to be processed by the main session.

You can manage this process manually using CLAUDE.md, a progress file, and git, or leverage various tools designed to help with specific aspects of long-running sessions.

For example, claude-mem captures what the agent does, compresses the information, and injects relevant context into future sessions. context-mode prevents tool output from flooding the window and maintains session memory, while claude-auto-handoff replaces the auto-compact feature with a structured brief, a /clear command, and a fresh session. Hindsight is a memory service built to learn across agents, but it can be used in conjunction with other tools.

The author of a sample harness called aigent-OS has created an open-source solution that refreshes context instead of compacting. When the context reaches 80% capacity, the harness prompts Claude to write a capsule, clears the session, and resumes from the capsule. Memory is stored in plain markdown files in a git repository. The harness is MIT licensed, runs locally, and requires Node 18.

While running multiple instances of the harness on my newsletter, I observed that three out of four seats would have resumed into a checkpoint with no actionable content. To address this, the capsule selector has been updated to refuse such checkpoints, and a test in the repository defends the fix. Stale notes also present an issue, so assigning a validity window to notes and ranking them below current ones once the window expires can help.

Memory that attempts to provide instructions is held before being saved, and saved memory is read back as data, not commands.

The harness is currently at version 1.1.0-rc.1, and a long session can stall at the clear step, requiring a manual /clear command. The fixes are merged on master and will be included in the next release. Some minor acknowledgement bugs remain open as #90 and #91, so it's essential to ensure the latest capsule is saved before clearing the session manually.