# Cloud Skills Recall reusable, versioned procedures progressively and execute only their declared script components inside the Cloud Skill sandbox. - Canonical: https://docs.xmemo.dev/docs/concepts/cloud-skills - Locale: en-US - Content-Locale: en-US - Canonical-Content-Digest: 46b29ef7823519fa1741650528935c0b97cc0f83ddce3ca0cfbd35c3e20c234b - Edition-Digest: d17bf12cea3b8a206839a9b4055863a373d537a8391ac75a1773fd0dd80ddad9 - Source-Revision: sha256:58890584e5990bf8fd6fe087c16015adee29936ae391a944d7bc1441c855a45f ## 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. ```text 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="", 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. ```json { "kind": "root", "data": { "skill_id": "", "revision_id": "", "revision_number": 2, "canonical_hash": "", "resources": [ {"logical_path": "scripts/check.py", "type": "script", "content_hash": ""} ] } } ``` ## 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. ```text execute_cloud_skill( slug="deployment-procedure", revision_id="", 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. ```text bwrap available + probe passes -> isolated execution bwrap unavailable + fallback off -> SANDBOX_UNAVAILABLE fallback on explicitly -> unsafe local process isolation ``` ## ChatGPT user Give ChatGPT durable access to your XMemo preferences, project facts, decisions, and TODOs without pasting bearer tokens into a chat. Connect the hosted XMemo MCP server through the ChatGPT/OpenAI app OAuth flow, then approve the memory:read and memory:write grant for your XMemo account. Save a synthetic preference or project note, start a new chat, then ask ChatGPT to recall it through XMemo before continuing work. If OAuth fails or tools do not appear, sign out of the MCP server in the host app, reconnect the XMemo server URL, and retry before creating direct tokens. ## Copilot / Codex developer Carry repo decisions, coding conventions, bug-fix notes, and task history between IDE and CLI agents. Use OAuth for VS Code / GitHub Copilot and Gemini CLI when available. For Copilot CLI, Codex, Cursor, or other direct MCP clients, keep XMEMO_KEY in the local environment or secret store and set a stable XMEMO_AGENT_INSTANCE_ID. Record a codebase decision or bug fix, then ask the next IDE or CLI agent to recall the relevant XMemo context before editing. If recalls are empty, verify the selected MCP config path, the XMEMO_KEY environment variable for direct clients, and any stale OAuth credential in the host app. ## Team / enterprise pilot owner Evaluate shared memory with account controls, source attribution, export/delete workflows, and reviewer-safe setup evidence. Create or enter the protected XMemo workspace, invite approved users, then connect each client through OAuth or a scoped direct credential according to the readiness badges. Have a pilot member save a synthetic team memory, confirm source attribution in XMemo, then review delete/export and support paths. If a member cannot connect, check role permissions, OAuth approval, client readiness status, and support guidance before issuing a new token. ## Autonomous agent operator Let headless or scheduled agents record progress, retrieve prior decisions, and keep a stable non-secret instance identity. Fetch /api/v1/mcp/config/autonomous-agent. Prefer auth_modes.oauth when the runner supports OAuth + custom headers; use auth_modes.xmemo_key with XMEMO_KEY from a secret store only for fully headless runners. Run one synthetic task that writes progress to XMemo, restart the runner, and confirm it recalls that progress using the same XMEMO_AGENT_INSTANCE_ID. If attribution changes or recalls split across instances, persist XMEMO_AGENT_INSTANCE_ID outside git and verify the runner is not regenerating it on every start.