Context

Context is the information an Agent uses to do your work: instructions, conversation, repositories, files, Skills, and Memory. You choose the sources and how their versions are selected. The selected Harness determines how the Agent receives and uses them. For example, give a support Agent a product repository, a troubleshooting Skill, and a MemoryStore of approved answers. Ask it to explain a failed upgrade. Checkfu records the exact versions selected for that user turn. If the Agent pauses for an answer while you publish a new troubleshooting Skill, the waiting work keeps its original version. A later user request can select the new version.

​

Choose the inputs

Use Session resources to attach files, repositories, and Memory through resources[]. Configure Skills on the Agent; see Install a Skill. Each Session owns its resource selection. It does not follow a live reusable Session template. A Skill can explain how to publish a release. It cannot grant the Tool, provider account, credentials, or permission to publish one. The same rule applies to repository instructions and Memory. Configure actions separately through Tools.

​

Resolve a user turn

Starting a Session fixes its AgentVersion, Skill references, and resource selection policy. It does not freeze every latest source for the Session’s entire life. When a new user turn becomes eligible to run, Checkfu resolves its selectors and records exact versions and content digests. A configured exact version stays on that version. A latest selector can pick up a publication made since the previous turn. An additional authorized Skill activation can be pending for a later eligible turn; it does not rewrite active work. Tool rounds, answers to questions, approvals, retries, and recovery continue the same Run. They retain the original resolved inputs rather than looking up latest again. A new independent request has its own Run and context selection. See Sessions and Runs. Memory can also advance through that input’s own retained, committed write checkpoints on a supported path. Each later round records its exact revision and write provenance; retries preserve those records. This does not select unrelated changes to today’s Memory. See Memory.

​

Keep access current

A version pin identifies content; it does not grant lasting access. Discovery, reads, writes, reuse, and publication require current authorization. Recovery cannot restore a revoked permission or recover content that retention or erasure has removed. If an original required input is missing or no longer authorized, continuation refuses or reports unavailable. It does not replace that input with a newer version, a resource with the same name, or another account. Content also keeps its audience restrictions. A personal MemoryStore or native private memory does not become Workspace knowledge because a Session used it. Shared adoption and later reuse follow the existing resource’s permissions, retention, and promotion rules.

​

Files and file trees

Use a File mount for one uploaded file and a FileTree for a file tree or Git repository. Both resolve through the same mount machinery: destinations cannot overlap, staged bytes are digest-verified, and session.resources_resolved records the exact inputs selected for a Run, including version and content provenance. It is not a receipt that the harness read those bytes or used the instructions. Verify use through the Run’s actual output and supported harness evidence; successful selection alone does not qualify native execution or recovery. FileTrees add immutable revisions. A mount may pin one revision or follow latest; latest resolves to a concrete revision for each new eligible turn. Question answers and custom Tool results continue the same Run with that turn’s full original resolved resource manifest. A revision published while the turn is waiting becomes eligible for a later turn; it does not replace the original continuation inputs. If those original resources cannot be used under current authority, continuation refuses rather than selecting a newer revision. Writable overlays remain disposable unless a Git-backed FileTree explicitly enables pull-request writeback. GitHub is therefore one provider-specific path through FileTrees and governed Connections, not a separate context system. On the FileTree compatibility path, a repository mount announces Skills discovered at exactly .claude/skills/<name>/SKILL.md in the frozen revision — for a Git FileTree that is the resolved version, and for a github_repository Session Resource it is the checked-out commit. They stay at their repository paths and never become catalog Skills or release pins. When the Agent has its built-in read tool, the prompt points to the generated read-only index at /environment/.checkfu/repository-skills.md; without read, no pointer is added. Mounting the repository admits those instructions into the Agent’s trust boundary, so review that directory for repositories that accept outside contributions. Nested, rootless, and package-local layouts are not announced. Native recorded-Git preparation currently does not discover or load those repository-local Skills. Configure reusable Skills through their versioned resource contract; recording a repository revision does not activate them. See Session resources for the wire shapes and FileTrees for upload, Git, and writeback behavior.

​

Native Session resource boundaries

Resource delivery depends on the selected Harness. A native file adapter can expose bounded read-only files and directory readers without creating a writable sandbox checkout. Do not infer shell execution, file mutation, or watches from a readable mount. Git-backed FileTrees retain their original Connection and exact recorded revision; a missing source leaves that namespace unavailable rather than selecting another source. The current native uploaded-tree reader requires an acting Principal. An API-key Session without acted_as cannot use that body-reading path, even if the tree’s metadata was selected. This is a delivery limitation; specifying acted_as still requires the real delegation and resource permissions. Native Workspace execution does not currently publish generated artifacts as downloadable Session Files. A retained Tool result or a readable input mount does not establish that output path. Use the selected Harness’s supported capture and File publication path before relying on downloads or reuse in another Session. Private Workspace state and native private memory are not automatically published or shared. Memory writes use their own governed writer. A writable mount needs the original write offering and current write permission; mount metadata alone does not enable it. See Memory for working refs, checkpoints, and supported read and write paths. Selection, staging, actual use, and retention are separate steps. A resolved revision or successful directory read does not show that the Harness read the file’s bytes. Retained conversation does not establish that files or native continuation state survived. Check the selected Harness’s capability status and the Run’s output before relying on a particular delivery or recovery path.

​

Memory

Memory is durable, governed knowledge that can outlive any one Session. A mount requests read_only or read_write access; admission checks the Agent’s PermissionAssignments for a resources[] attachment. When a Principal is part of the acting authority, its PermissionAssignments are checked too. Current permissions are checked again when the Run uses Memory. Shared stores owned by a Workspace, Agent, or CollaborationSpace mount read-only in Sessions. Shared canonical changes follow the store’s write and promotion policy; that policy does not grant Session writers direct canonical access. Principal-owned writes stay on the Session’s working ref and do not silently become another Session’s input. To reuse a writer’s retained output, take new_version from its memory.change_checkpointed event and attach the store with access: "read_only" and selection: { kind: "version", version: new_version }. A named ref selection resolves to an exact revision before the Run; a selected MemoryVersion identifies one immutable tree. Where the native versioned writer is installed, an explicit selection on an effective read_write mount fixes the base of that Session’s working ref; it does not edit the selected immutable revision. An existing working ref at a different version refuses that base. Mount paths without this writer refuse explicit selections on effective read_write mounts. The Session detail shows declared selection intent, not a frozen Memory input or native-use receipt. Verify delivery through the relevant Run and attempt inputs. Neither selection nor a checkpoint receipt grants access or extends retention: revoked permissions, expired bodies, and erasure still apply. See carry a sealed revision into another Session for the complete request. Memory is not hidden conversation history. Stores and their MemoryVersions are addressable, access is explicit, and writeback settles through its own durable lifecycle.

​

Context windows and condensation

The Session event log remains the durable record even when a model cannot read the entire history in one request. Checkfu bounds model input without rewriting that record. Automatic compaction is currently disabled for native Sessions; their Managed Agent snapshot does not carry the compaction_policy described below. Do not treat a successful native reply or retained history as proof of compaction support. For execution paths that support these mechanisms:

• request-time compaction follows the published Agent version’s compaction_policy and the admitted model route’s context window;
• between turns, structural condensation can replace an older conversational prefix with an explicit elision marker while retaining the newest tail;
• session.compacted and session.context_condensed make both boundaries observable.

GET /v1/sessions/{id}/ledger reports current and cumulative context tokens, loaded Tool and Skill references, compactions, and condensations without returning prompts or messages. Use the context ledger guide when you need to explain what was loaded and what it cost.

​

Next steps