Recall reusable, versioned procedures progressively and execute only their declared script components inside the Cloud Skill sandbox.
A Cloud Skill is a versioned procedure
In XMemo, Cloud Skills represent user-authored procedural memory: users save their own skills, standard operating procedures (SOPs), checklists, and workflows directly into procedural memory. Once saved, connected agents and clients (including Claude, Cursor, ChatGPT, Codex, and CLI tools) can recall and reuse them without repeated per-agent installation or manual copy-pasting. A user-authored Cloud Skill is distinct from the standalone XMemo Skill client runtime (which connects agents over direct HTTPS). Each skill has a stable skill_id and slug, an owner scope, an active or archived asset status, and immutable SkillRevision records containing instruction_body, canonical_metadata, a canonical_hash, and typed SkillComponent resources.
- Procedural memory: users save reproducible runbooks, SOPs, and checklists to reuse across connected agents without per-agent setup.
- Instructions are required and limited to 64 KiB after UTF-8 encoding.
- A revision can contain up to 50 components; each component is limited to 128 KiB.
- Components use declared types such as reference, example, template, document, artifact, or script.
- Personal publish intent produces a published revision; team publish intent produces a proposed revision for review.
Progressive recall: Level 0, Level 1, Level 2
Skills are recalled strictly on demand using Progressive Recall to prevent bloating LLM context windows. Level 0 discovers matching published skills from a query and returns lightweight descriptors. Level 1 recalls the selected skill's published root instructions and resource manifest. Level 2 recalls a single resource component, but only when the caller pins the revision_id returned by Level 1.
recall_cloud_skill(query="deployment procedure") # Level 0: descriptors
recall_cloud_skill(slug="deployment-procedure") # Level 1: root + manifest
recall_cloud_skill(
slug="deployment-procedure",
revision_id="<revision-id-from-level-1>",
resource="scripts/check.py",
) # Level 2: one pinned resource
Revision pinning prevents resource tearing
A new save for an existing slug creates the next immutable revision instead of mutating the previous snapshot. Level 1 defaults to the published revision, with a latest-revision fallback when no published revision exists. Level 2 refuses an unpinned resource request and continues to read the exact revision supplied by the caller, so a resource cannot silently change during a workflow.
{
"kind": "root",
"data": {
"skill_id": "<skill-id>",
"revision_id": "<immutable-revision-id>",
"revision_number": 2,
"canonical_hash": "<sha256>",
"resources": [
{"logical_path": "scripts/check.py", "type": "script", "content_hash": "<sha256>"}
]
}
}
Execute a declared script component
Sandbox and script execution is an optional automation capability, not the core product story: most Cloud Skills are prompt-executable SOPs interpreted directly by agents. When automation is required, execute_cloud_skill resolves the skill in the caller's scope and executes only declared script components inside SandboxExecutionEngine with JSON stdin. Valid JSON stdout becomes output_data, while stdout and stderr remain bounded result fields.
execute_cloud_skill(
slug="deployment-procedure",
revision_id="<revision-id-from-level-1>",
script_path="scripts/check.py",
input_args={"environment": "staging"},
timeout_seconds=30,
)
The sandbox boundary is explicit
On a host with a working bubblewrap driver, the executor uses unshared user, PID, network, IPC, UTS, and cgroup namespaces; unshares the network; mounts system paths read-only; gives the process a virtual proc and minimal dev filesystem; mounts a 64 MiB /tmp tmpfs and the script scratch path read-only; and uses a hermetic environment allowlist. The script runtime is inferred from .py, .sh/.bash, or shebang, with Python 3 as the fallback.
- ExecutionLimits defaults are timeout 30 seconds, max memory 256 MiB, 0.5 CPU cores, 32 processes, and 1 MiB per stdout/stderr stream; timeout is constrained to 1–60 seconds.
- The watchdog terminates timed-out work, records timeout/runtime/OOM/system status, and truncates oversized streams.
- The engine emits structured execution telemetry and an immutable audit log entry with IDs, status, timing, and resource fields.
Fail closed when isolation is unavailable
If bubblewrap is missing or its namespace probe fails, execution returns SANDBOX_UNAVAILABLE instead of running a script locally when unsafe fallback is disabled. The local process-isolation fallback exists only when XMEMO_SANDBOX_ALLOW_UNSAFE_LOCAL_FALLBACK=1 is explicitly enabled, and the engine logs that this mode must not be used for production multi-tenant execution. These are the implemented runtime boundaries; the page does not promise a stronger sandbox than the host can provide.
bwrap available + probe passes -> isolated execution
bwrap unavailable + fallback off -> SANDBOX_UNAVAILABLE
fallback on explicitly -> unsafe local process isolation
Persona flows
ChatGPT user
Give ChatGPT durable access to your XMemo preferences, project facts, decisions, and TODOs without pasting bearer tokens into a chat.
Save a synthetic preference or project note, start a new chat, then ask ChatGPT to recall it through XMemo before continuing work.
Copilot / Codex developer
Carry repo decisions, coding conventions, bug-fix notes, and task history between IDE and CLI agents.
Record a codebase decision or bug fix, then ask the next IDE or CLI agent to recall the relevant XMemo context before editing.
Team / enterprise pilot owner
Evaluate shared memory with account controls, source attribution, export/delete workflows, and reviewer-safe setup evidence.
Have a pilot member save a synthetic team memory, confirm source attribution in XMemo, then review delete/export and support paths.