Data locations

Jarvis Code CLI stores all runtime data — the config file, session history, login credentials, and diagnostic logs — under ~/.jarvis-code/. This page helps you understand where each type of data lives, what it is for, and how to clean up or relocate it when needed.

Data root directory

The default data root is ~/.jarvis-code/. The actual path varies by platform:

macOS: /Users/<name>/.jarvis-code
Linux: /home/<name>/.jarvis-code
Windows: C:\Users\<name>\.jarvis-code

If you need to move the data directory elsewhere (for example, to isolate configs for different projects with independent environments), set JARVIS_CODE_HOME:

export JARVIS_CODE_HOME="$HOME/.config/jarvis-code"

Once set, all Jarvis Code data — config, sessions, logs, OAuth credentials, Jarvis Code-specific user Skills, global AGENTS.md, and more — lands under the new path. For the full reference on JARVIS_CODE_HOME, see Environment variables.

Note

Generic .agents resources stay under the real OS home so they can be shared across tools. For example, user-level generic Skills remain at ~/.agents/skills/, while Jarvis Code-specific user Skills move with JARVIS_CODE_HOME as $JARVIS_CODE_HOME/skills/.

Directory layout

$JARVIS_CODE_HOME  (default: ~/.jarvis-code)
├── config.toml             # User configuration
├── tui.toml                # Terminal UI preferences (including auto-update toggle)
├── AGENTS.md               # Global Jarvis Code-specific agent instructions (optional)
├── mcp.json                # User-level MCP server declarations (optional)
├── skills/                 # Jarvis Code-specific user-level Skills (optional)
├── plugins/
│   ├── installed.json      # Installed plugin records and enabled state
│   └── managed/            # Plugin copies installed from zip/local paths
├── session_index.jsonl     # Session index
├── credentials/            # OAuth credentials (dir 0700, files 0600)
│   ├── <name>.json
│   └── mcp/
│       └── <key>-<suffix>.json
├── memory/                 # Persistent-memory records (engine v2; optional)
│   ├── user/
│   │   └── <ulid>.json
│   ├── workspace/<workspaceId>/
│   │   └── <ulid>.json
│   └── project/<workspaceId>/
│       └── <ulid>.json
├── sessions/               # Session data (see below)
│   └── <workDirKey>/<sessionId>/
├── bin/
│   ├── rg                  # managed ripgrep binary for Grep (rg.exe on Windows)
│   └── fd                  # managed fd binary for file references (fd.exe on Windows)
├── search-index/           # MiniDB index behind global session search (server)
├── server/
│   └── instances/          # One JSON record per running `jarvis server` instance
├── server.token            # Persistent bearer token for `jarvis server` (file 0600)
├── logs/
│   └── jarvis-code.log       # Global diagnostic log
├── updates/
│   ├── latest.json
│   ├── install.json
│   ├── install.lock
│   └── rollout.log
└── user-history/
    └── <md5(workDir)>.jsonl

File descriptions

Each top-level file under the data root serves a specific purpose; most are managed automatically by the CLI:

config.toml: the main runtime configuration file, storing user-level settings such as providers, models, and loop control. See Configuration files.
tui.toml: terminal UI client preferences, including [upgrade].auto_install (auto-update, on by default). You can disable it in /settings or by manually setting auto_install = false.
AGENTS.md: global Jarvis Code-specific agent instructions. This file moves with JARVIS_CODE_HOME; generic cross-tool instructions can still live under ~/.agents/AGENTS.md.
mcp.json: user-level MCP server declarations, merged with the project-local .jarvis-code/mcp.json on startup. See MCP.
skills/: Jarvis Code-specific user-level Skills. This directory moves with JARVIS_CODE_HOME; generic cross-tool Skills can still live under ~/.agents/skills/. See Agent Skills.
plugins/installed.json: records installed plugins, each plugin's enabled state, and MCP server capability state changes made via /plugins or /plugins mcp disable|enable. Files installed from local paths or zip URLs are copied to plugins/managed/<id>/. See Plugins.
credentials/: OAuth credential directory, with permissions 0o700 (directory) / 0o600 (files), readable and writable only by the current user. Managed provider credentials are stored as credentials/<name>.json; MCP server credentials are stored under credentials/mcp/. Credentials are written using an atomic flow (tmp → fsync → rename) to prevent corruption.
memory/: Optional engine v2 persistent-memory records. Each record is one JSON document at memory/<scope>/<id>.json: user/<ulid>.json for global user memory, workspace/<workspaceId>/<ulid>.json for workspace memory, or project/<workspaceId>/<ulid>.json for project memory. The workspace id is the encoded working-directory key (wd_<slug>_<12-char-sha256>).
search-index/: the MiniDB index that backs global session search in jarvis server. It is derived data, rebuilt by scanning the wire files, so deleting it is safe.
server/instances/: one JSON record per running jarvis server instance, used so several instances can coexist on one home directory. Dead records are swept automatically.
server.token: the persistent bearer token for jarvis server, written with mode 0600 and shared by every instance under this home directory. Rotate it with jarvis server rotate-token.

Note

Tower mode does not write under the data root. Its workspace lives at .tower/ inside the repository being worked on. See Tower mode.

Session data

Each session's data is stored under sessions/<workDirKey>/<sessionId>/, and a top-level session_index.jsonl index is maintained (one record per line, each containing sessionId, sessionDir, and workDir). workDirKey is a bucket name derived from the working directory path, in the format wd_<slug>_<first-12-chars-of-sha256>.

Inside each session directory:

state.json: session metadata including title, lastPrompt, creation/update timestamps, and forkedFrom.
upcoming-goals.json: the TUI-only queue created by /goal next <objective>. It is not part of the agent conversation until a queued goal is promoted after the current goal completes.
agents/main/wire.jsonl: the main Agent's complete communication record, used for session resumption and replay.
agents/main/plans/: plan files written in Plan mode, named by plan id (<id>.md).
agents/agent-0/ etc.: sub-Agent instance directories, each containing their own wire.jsonl.
logs/jarvis-code.log: diagnostic log for this session; only present when a diagnostic event occurs.
tasks/: background task persistence — tasks/<task_id>.json stores status/pid/exit code; tasks/<task_id>/output.log stores output.
cron/: scheduled task persistence; reloaded into the scheduler when the session is resumed with jarvis --session. See Scheduled tasks.

Built-in tool cache

The first time the Grep tool needs ripgrep, the CLI can automatically download rg and cache it at bin/rg (bin/rg.exe on Windows). File-reference completion in the terminal UI uses fd; the CLI downloads and caches it at bin/fd (bin/fd.exe on Windows) in the background when needed. Subsequent runs reuse the cached binaries. rg prefers the system PATH before the cache, while fd checks the managed cache before falling back to system fd / fdfind. Deleting the bin/ directory triggers a fresh download on the next use.

Logs and update state

logs/jarvis-code.log (global): records startup, login, export, and other cross-session events.
<sessionDir>/logs/jarvis-code.log (session-level): records diagnostic events within a single session.

When reporting a bug, prefer exporting the relevant session with jarvis export; the session log is included in the export by default. Add --no-include-global-log if you do not want to share the global log.

The files under updates/ (latest.json, install.json, install.lock, rollout.log) are maintained automatically by the auto-update mechanism and normally do not need manual editing. rollout.log records which staged-rollout case each update check hit, which helps explain when a device will receive a new release.

Input history

Terminal input history is saved separately per working directory, at user-history/<md5(workDir)>.jsonl. It is used to browse previously typed prompts in the terminal UI using the arrow keys.

Clearing data

Deleting the data root directory (~/.jarvis-code/ or the path set by JARVIS_CODE_HOME) removes all runtime data. To clear only part of the data:

Goal	Action
Reset configuration	Delete `~/.jarvis-code/config.toml`
Reset terminal UI preferences	Delete `~/.jarvis-code/tui.toml`
Clear all sessions	Delete `~/.jarvis-code/sessions/` and `session_index.jsonl`
Clear diagnostic logs	Delete `~/.jarvis-code/logs/`
Clear input history	Delete `~/.jarvis-code/user-history/`
Reset update state	Delete `~/.jarvis-code/updates/latest.json`
Force re-download of managed `rg` and `fd`	Delete `~/.jarvis-code/bin/`
Clear provider OAuth login state	Run `/logout`, or delete the corresponding `credentials/<name>.json`
Clear MCP server OAuth login state	Delete `credentials/mcp/` (`/logout` does not clear MCP credentials)
Remove user-level MCP declarations	Delete `$JARVIS_CODE_HOME/mcp.json` (default `~/.jarvis-code/mcp.json`)
Clear global Jarvis Code-specific agent instructions	Delete `$JARVIS_CODE_HOME/AGENTS.md` (default `~/.jarvis-code/AGENTS.md`)
Clear plugin install records	Delete `$JARVIS_CODE_HOME/plugins/` (local plugin source directories are not affected)
Clear Jarvis Code-specific user-level Skills	Delete `$JARVIS_CODE_HOME/skills/` (default `~/.jarvis-code/skills/`)
Clear persistent memory	Delete `$JARVIS_CODE_HOME/memory/`
Rebuild the session search index	Delete `$JARVIS_CODE_HOME/search-index/`; the server rebuilds it on the next search
Invalidate the server bearer token	Run `jarvis server rotate-token`, or delete `$JARVIS_CODE_HOME/server.token`

Next steps

Configuration files — full reference for config.toml fields
Environment variables — detailed usage of JARVIS_CODE_HOME and related path variables

Data locations ​

Data root directory ​

Directory layout ​

File descriptions ​

Session data ​

Built-in tool cache ​

Logs and update state ​

Input history ​

Clearing data ​

Next steps ​