rekall
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CODEX_HOME | No | Base directory for Codex configuration. Defaults to ~/.codex. Used to locate the jobs directory when REKALL_JOBS_DIR is not set. | ~/.codex |
| REKALL_PIPE | No | Pipe name or transport identifier used for tests to deliberately skip the schema subprocess. | |
| CODEX_THREAD_ID | No | The exact current thread ID used by CLI commands when the optional threadId argument is omitted. | |
| REKALL_JOBS_DIR | No | Alternative local journal directory for Rekall jobs. Defaults to $CODEX_HOME/tools/rekall/jobs (or ~/.codex/tools/rekall/jobs when CODEX_HOME is unset). | $CODEX_HOME/tools/rekall/jobs |
| REKALL_CODEX_BINARY | No | Absolute path to the extension-bundled executable to use when Rekall cannot automatically locate a unique one. | |
| REKALL_ALLOW_UNVERIFIED | No | Set to exactly 1 to bypass the extension version verification gate for deliberate compatibility investigation. Any other value disables the override. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| probe_compactionA | Read-only preflight for an extension-owned Codex VS Code chat on Windows, macOS, or Linux. Run after compaction_status and before schedule_compaction to verify the exact owner/thread, extension version, runtime layout, public schema, and IPC access. It does not compact or prove live compaction compatibility; layout_compatible means only that the required layout was found. Standalone Codex CLI sessions are unsupported because they have no VS Code extension owner. Use compaction_status instead to inspect an existing job. |
| schedule_compactionA | Schedule ONE compaction after this answer. Only when the user authorizes compaction. Optional handoff describes what to keep/summarize and is saved exactly in a per-job file. resume:true explicitly requests ONE subsequent turn with that handoff and nextStep; use only for authorized continuation. Cancels on observed new user input or a stopped turn. Return the handoff in context before finishing. Compaction prompt itself is not overridden. Check status later; no automatic retries. |
| compaction_statusA | Read-only local job inspection. Run before probe_compaction or schedule_compaction to detect an unfinished job, and after scheduling or cancellation to inspect its exact outcome and metrics. It does not probe extension compatibility. scheduled, waiting_for_idle, requesting, and accepted are intermediate; completed requires a newly observed completed contextCompaction event. resumed identifies a returned continuation turn, not successful work. Missing or stale post-compaction telemetry can skip automatic continuation with insufficient_headroom. |
| cancel_compactionA | Cancel pending compaction or continuation dispatches only for the exact job returned by schedule_compaction or compaction_status. Already sent requests cannot be undone. Use compaction_status for observation and inspect it after cancellation. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 4 tools
Each tool covers a distinct part of the compaction lifecycle: probe checks preflight compatibility, schedule creates a job, status inspects job state, and cancel aborts pending jobs. There is no meaningful overlap, and the descriptions reinforce the correct ordering and separation of responsibilities.
Three tools follow a clear verb_noun pattern: probe_compaction, schedule_compaction, and cancel_compaction. compaction_status deviates slightly by using noun_noun instead of a verb-led form like get_compaction_status, but the overall snake_case convention and recognizable pattern keep the set highly readable.
Four tools is exactly the right scope for a compaction lifecycle management server. Each tool has a distinct role and none feel redundant or missing, making the surface compact and focused.
The tool set covers the full job lifecycle: compatibility probing, scheduling, status inspection, and cancellation. There are no obvious dead ends for the stated purpose, and the explicit sequencing guidance reduces gaps in workflow coverage.