Skip to main content
Code Storage enables agent memory with exact reads, safe concurrent changes, and a history that can be inspected and reverted.

Choose the repository and exact version

Use a separate memory repository when the information needs its own access rules, storage lifetime, or delete boundary. You can use one repository per project, user, tenant, or company. Before the agent reads memory, read the current commit SHA of the branch and store it with the agent session. This SHA is the pinned revision. It always identifies the same files, so the agent reads one exact version.
Use createTag() when a person needs a readable name for the version.

Load only the required files

Give the sandbox a temporary API token for only the memory repository. Keep the organization private key in trusted product code. See Authentication & Security for token details. Use getArchiveStream with file patterns to fetch a group of memory files without a git clone. Use getFileStream for one file. The sandbox needs no local Git index and no git push.
The path above is only an example. Your product chooses the paths and file format. Use subpaths within one memory repository when every group shares the same access rules, storage lifetime, and delete boundary. For example, a product can use one subpath for each project. A ref policy limits Git branches and tags, not file paths, so enforce subpath access in your product. If the product needs ordinary Git tools, it can create temporary Git URLs instead. See Connect a Sandbox and Ref Policies.

Save the agent’s changes

Set expectedHeadSha to the commit SHA that was current before the agent made its change. Code Storage accepts the save only if the target branch still points to that commit.
A conflict means that another agent saved first. Do not send the old file content again. Load the current files, apply the intended change to them, and save again with the new commit SHA. An identical file set returns precondition_failed; the branch still points at the pinned revision. Treat it as success with no new commit. After a timeout, the save can still have succeeded. Do not resend the same request. Read the current head again, apply the intended change to the current files, and save with the new head as expectedHeadSha.

Combine changes from separate branches

A product can give each agent session its own branch. Check the merge first, then require main to remain at the commit that you checked.
If the check finds a conflict, load the listed files. Decide in code how to combine both changes before you save again. If the merge itself fails because main moved after the check, run the check again on the new head.

Inspect and undo a change

Use listCommits to show file history and getCommitDiff to show one change.
Use restoreCommit to create a new commit from an earlier version. The new commit keeps the undo action in history.
This example restores every file from the commit before the newest commit. To restore one file, read its earlier content and save it with a normal file commit. Use Manage Product Files when people edit a complete file set through a product interface. That workflow validates and applies each change before it becomes active.