Integrations

Every agent runtime ships its own ephemeral sandbox: the VM is torn down when the run ends, and everything the agent did dies with it. AIStor Memory gives that sandbox durable memory — one mount of an AIStor Memory Bucket (a cortex) the agent both works in and remembers through, so the work and the knowledge outlive the sandbox and re-mount into the next one.

Memory takes three forms on that one cortex:

• Workspace — active work. The real files the agent edits with the tools it already uses (git, editors, sqlite, build tools), surviving teardown because they live in the durable cortex, not in session residue.
• Long-term memory — what the agent learned. The memory files agents look for (CLAUDE.md, AGENTS.md, MEMORY.md) warmed on mount, writable per-object annotations, read-only object metadata and tags, and server-side search across the whole cortex.
• Vault — authority to act. The secrets an approved agent receives, leased into the agent at launch and never written to the mount.

The mount also warms the agent's memory and installs its skill during startup, so the model arrives oriented. Each page below walks an agent sandbox through using AIStor Memory end-to-end.

Status at a glance

Status reflects what you can run today, not aspiration:

• Ready — a working image / Feature / template you can build today from the public CDN binaries, exercised by an automated CI test that mounts and exercises the integration.
• Validated (experimental) — a working self-serve example has passed a live end-to-end smoke, but depends on a provider capability that the provider still labels experimental or Beta.
• Coming soon — the pieces exist but aren't packaged for self-serve yet.
• Requires vendor partnership — blocked on a change only the runtime vendor can make.

One clarification on the boundary cases:

• Codex Cloud (the hosted offering) is not supported: its container-snapshot lifecycle is incompatible with a live FUSE daemon. Self-hosted Codex sandboxes are Ready (above).

What every mount needs first

AIStor Memory mounts only a cortex — there is no plain-bucket mode. Before the mount succeeds, AIStor Memory verifies each of the following at startup:

• an explicit --endpoint-url flag (or the endpoint_url: config key) — the mount cannot be verified without one;
• real signing credentials (AIMEM_ACCESS_KEY / AIMEM_SECRET_KEY, optional AIMEM_SESSION_TOKEN) — anonymous or default-chain mounts are refused;
• a target that is already a cortex on a paid-tier AIStor deployment — create one with aimem cortex create <name> (see the CLI).

If any precondition fails, AIStor Memory exits before mounting with a specific message (e.g. '<bucket>' is not a Memory Bucket (cortex)).

Shared mount shape

Every integration ends up running the same invocation inside the sandbox: the positional cortex + mountpoint plus one --config YAML that carries every tunable. Credentials stay in the environment (AIMEM_ACCESS_KEY / AIMEM_SECRET_KEY) — never a flag, never in the YAML. The wrapper writes the config from the sandbox's env vars, so the mount command carries no other flags:

# /etc/aimem/mount.yaml — written by the wrapper from the sandbox env
version: "1.0"
endpoint_url: https://aistor.example.com # from $AIMEM_ENDPOINT
local: /var/cache/aimem
agent: auto # from $AIMEM_AGENT
foreground: true

aimem "${AIMEM_CORTEX}" "${AIMEM_MOUNTPOINT:-/workspace}" --config /etc/aimem/mount.yaml

The version: "1.0" key is required and must be a quoted string. For pure env-var-driven sandboxes that carry no config file, every YAML key is also a flag or AIMEM_* env var — the staging directory, for example, via --local "${AIMEM_LOCAL}" or the AIMEM_LOCAL env var. --config remains the canonical form.

Each integration bakes this into a small aimem-mount wrapper that maps environment variables to those flags, so the runtime only has to inject env vars — the shape every sandbox already supports. Credentials, including the optional AIMEM_SESSION_TOKEN, are read from the environment and never baked into an image. What changes per runtime is how the binary lands (a baked-in image asset, a devcontainer Feature, a host-side install) and how env vars are injected. See Quick start and Configuration for the full config vocabulary.

The staging directory is required

AIStor Memory stages every open-for-write file on fast local storage and uploads atomically on close — that's what lets git, editors, sqlite, and the rest of the agent's tools work over an object store. (mmap and copy_file_range return ENOSYS, but the kernel falls back to read+write over that same staging file, so memory-mapped tools still function.)

There is no auto-detection. Set the staging directory with the local: key in a --config YAML (canonical), the --local <DIR> flag, or the AIMEM_LOCAL environment variable — at least one of the three, and the flag or env var wins when more than one is set. Size it for the agent's expected open-write working set — NVMe is recommended. See the aimem page for the full write-up.

What AIStor Memory brings to a sandbox

The three forms of memory, as a sandbox sees them:

• Workspace — a durable mount. Sandbox VMs are ephemeral by design; the cortex survives the VM. The agent's working files are real files that persist to AIStor, so you can hand off a session ID and resume the same workspace on the next one.
• Long-term memory, warmed on mount. CLAUDE.md, .claude/, AGENTS.md, .cursorrules, etc. are warmed onto local disk on mount, so the agent's first read is a hit. Writable per-object annotations (.aimem/annot/…), read-only object metadata and tags, and server-side search round out durable long-term memory across the whole cortex — the same cortex the workspace lives in.
• Vault — secrets, leased at launch. aimem secret provision fetches the granted secrets and injects them into the agent as environment variables at launch. By default it reads them from the cortex over the Memory API (--cortex); when they already live in a generic HTTP secret store (--store-endpoint, e.g. HashiCorp Vault/OpenBao), it reads them from there instead as a bridge. The source credential stays with the launcher and is scrubbed from the agent's environment; aimem persists no secret bytes locally.
• The aimem skill, three ways. Every mount teaches the agent how to use all of the above — no --flag required. (1) A read-time preamble overlay prepends AIStor Memory-usage guidance to instruction files (CLAUDE.md / AGENTS.md / .cursorrules) as they are read from the mount — in memory only, disabled when the mount root is a git repo, opt out with AIMEM_PREAMBLE_OVERLAY=0. (2) On every mount AIStor Memory installs the skill into $HOME/.agents/skills/aimem/ (Codex CLI, Cursor, Gemini CLI, Copilot) and $HOME/.claude/skills/aimem/ (Claude Code) — offline, create-only, opt out with AIMEM_INSTALL_SKILL=0. (3) For agents whose reasoning runs outside the sandbox, npx skills add minio/skills/aimem pulls it from github.com/minio/skills. See the aimem page for the full write-up.

Picking a starting point

If you're operating one of the listed runtimes already, jump to the matching page. The Ready rows — OpenAI Codex / Agents SDK, Codespaces, Daytona, E2B, Vercel Sandbox, OpenShift, OpenSandbox — are self-serve today: an image, a Feature, a template, or a host-mount script that installs the released binaries from the public CDN. Modal VM Sandbox and Apple container are validated experimentally. OpenShell is close behind. Devin needs a change only its platform team can make.