How to Maintain Context Across AI Sessions

Every coding agent session starts empty. Claude Code says so in its own documentation: each session begins with a fresh context window. The tool remembers nothing you told it yesterday unless something outside the conversation carried it forward. Learning how to maintain context across AI sessions is therefore not one trick; it is knowing which of four layers a given piece of context belongs in, and putting it there before the session ends.

This guide walks the four layers in order: instruction files the tool reads at launch, notes the tool writes for itself, session resume, and the shared work record that none of the first three provide. The first three are features of Claude Code, Codex, and Gemini CLI. The fourth is where Sharkly fits, because a Task that carries the goal, the discussion, the runs, and the acceptance is the only layer a second person can read. If you are still deciding between chatting and assigning, our guide to chat with an AI agent or assign a Task is the companion piece.

TL;DR

Context survives a session in four places. Instruction files (CLAUDE.md, AGENTS.md, GEMINI.md) carry rules the tool should hold every time. Auto memory carries corrections and preferences the tool learned. Session resume carries one conversation forward for one person on one machine. The work record, a Task with its description, comments, and execution log, carries what was decided, what ran, and what a person accepted, and it is the only layer that is shared. Put each kind of context in its layer and the fresh context window stops being a loss.

Layer 1: Instruction files the tool reads at launch

Instruction files are context you write once and the tool loads every session. Each major CLI has one, and they resolve in similar ways.

Two habits keep this layer useful. Keep files short: Claude Code’s guidance targets under 200 lines per file, because adherence drops as the file grows. And write facts you would otherwise re-explain, such as build commands, conventions, and the rule you typed into chat last session. If a repository already has an AGENTS.md, a CLAUDE.md that contains only @AGENTS.md imports it, so both tools read one source. Everything in this layer is context rather than enforcement; the Claude Code memory documentation is explicit that a hook, not an instruction, is what blocks an action.

Layer 2: Notes the tool writes for itself

Claude Code’s auto memory is the layer people forget exists. As it works, Claude saves notes about your role and preferences, corrections you give it, project context it cannot derive from the code, and where to find things outside the repository. They live at ~/.claude/projects/<project>/memory/, indexed by a MEMORY.md whose first 200 lines or 25 KB load at the start of every session. Topic files load on demand.

Three boundaries matter. Auto memory is per repository, shared across worktrees. It is machine-local, so notes on your desktop do not exist on your laptop. And it survives /compact, because compaction rewrites the conversation, not the files on disk. To see what was saved, run /memory; to turn it off, set autoMemoryEnabled to false or export CLAUDE_CODE_DISABLE_AUTO_MEMORY=1.

Use this layer for the kind of thing you say once and expect to stick: “always use pnpm,” “the API tests need a local Redis.” Do not rely on it for decisions a teammate needs; it is yours alone.

Layer 3: Session resume

Sometimes the context you need is the conversation itself. Claude Code keeps sessions on disk: claude --continue reopens the most recent conversation in the current directory, claude --resume <id-or-name> reopens a specific one, and --fork-session creates a new session ID so you can branch from a checkpoint without overwriting it. Rename a session with /rename before you /clear so you can find it again. Codex offers codex resume to reopen a recent chat from the current repository.

Resume has a cost. Every request carries the full conversation, so a long-lived session draws more usage for a one-line question than a fresh one. /compact with a focus instruction, such as /compact Focus on the migration plan, trades detail for room. What survives compaction is the summary plus whatever the instruction files reload; anything given only in conversation and not summarized is gone. Treat resume as a bridge across a lunch break, not as the team’s memory.

Layer 4: The work record

None of the first three layers answers the question a teammate asks on Thursday: what did the agent do on Tuesday, why, and who accepted it? Instruction files hold rules. Auto memory holds one person’s preferences. A resumed session holds one person’s conversation on one machine. The decision, the run, and the acceptance need a shared record, and that record is a Task.

In Sharkly, a task-backed run includes the Task title and description, recent comments and the comment that triggered the run, the Agent’s instructions and Skills, and the repositories configured for the Task. That is the context handoff: the next run starts from the Task, not from the previous session’s memory. Progress, trace events, and the result return to the Task, and the execution log records why a run was queued, when it started and ended, tool calls, the trigger source, and failure details.

Two rules from the product documentation decide where things go, and both are boundary rules rather than features. Standalone Agent Chat sessions belong to the person who created them and other members do not receive access; if the team needs a conclusion, copy it into the Task description or a comment. And the Agent chat on a Task is not a comment: it does not appear in Activity, so a decision made there is invisible unless someone writes it down. Our walkthrough of Claude Code project management shows the Task carrying a change from issue to review.

One more distinction is worth quoting because it is exactly the trap this article is about. A Crew can enable shared Task directory reuse, so a later Agent member’s run inherits the earlier member’s local changes on the same Computer. That setting shares filesystem state, not the previous Agent’s provider session. Files carry forward; the model’s conversation does not. If the second Agent needs the first Agent’s reasoning, it has to be on the Task.

Putting each kind of context in its layer

Skills earn their own row. A Skill packages reusable instructions and supporting files for guidance that should apply repeatedly, and a Skill discovered in a local Runtime directory can be imported into the organization so it stops living on one laptop. Our guide to Skills in Sharkly covers scope and binding, and what a coding agent skill is covers the file format.

Use instruction files and auto memory when the context is about how you work. Use a Task when the context is about what the team is building and someone else may need to read it. Sharkly is not a replacement for Claude Code, Codex, or other execution tools; it adds the shared record those tools do not keep.

FAQ

Does /compact lose my CLAUDE.md? No. The project-root CLAUDE.md is re-read from disk after compaction. Instructions given only in conversation can be lost; move those into the file.

Is auto memory shared with my team? No. It is stored under your home directory, per repository, and never synced. Team-visible context belongs in a checked-in instruction file or on a Task.

Can an Agent in Sharkly remember a previous run? It receives the Task, its recent comments, and the triggering comment on every run, which is the durable form of remembering. It does not receive the previous run’s private conversation. See Agents in Sharkly for what a run includes.

What about MCP memory servers? They add a fifth store the model can query, useful for structural recall of a codebase. They still do not record who accepted a change, so pair them with a work record rather than replacing one.