What radar stores and sends

Radar keeps service data, local work records and session pointers on your machine. Connected services and agent providers receive requests when their features run. This page explains that boundary and which local files you need to preserve. Back to the user guide.

Network

The service connection determines where its API credentials are sent. Pictures may be hosted elsewhere: GitLab and Jira attach credentials only on the configured origin; Slack also recognizes its own file hosts. External images are fetched without those service credentials. Opening a link delegates to your browser or the terminal’s link handler. Processes started by radar can make their own network requests.

Confirmed service writes follow radar’s mode. That mode is not a network or filesystem sandbox for local Git operations, terminal programs or agents. Agent approvals are described in Agents.

Coding agents

Claude Agent, Codex and Copilot use their provider’s authentication and session storage. Radar checks sign-in status and can start the provider’s sign-in flow; session transcripts remain provider-owned. Radar receives the live events needed to draw the dock and can read the provider’s saved transcript when you resume a session.

The agent receives your messages and the context included in its brief. A supplies the selected item and connected work; a manual or automatic review can supply the change, linked tickets, discussions and local checkout information. Enabling automatic Slack reviews allows qualifying requests to start this process without pressing A for each request. Reviews are saved as local Markdown and are not automatically posted to Slack or the code host.

Shared MCP context

Radar’s integrated provider sessions and external clients using radar mcp can read the same host context. They can query the host’s configured caches, not just the item used to start a particular session. Arbitrary programs in a PTY tab do not receive an injected MCP connection.

One context server belongs to the running radar host. It uses a local Unix socket in a private directory, checks the connecting user ID and requires the host’s discovery ticket. The directory is mode 0700; its socket and endpoint file are 0600. The ticket is shared by clients of that host, not a one-time ticket for one session. Closing one agent session does not stop the host’s context server; closing the host does.

The tools read configured cached sources. Captured context snapshots stay in host memory for up to an hour, subject to capacity eviction, and are invalidated when their configuration/account scope changes. Credentials are redacted from returned source text, but the returned work content can still be sensitive and becomes available to the receiving client/provider. See Connected context for the tools, coverage and snapshot limits.

Files

XDG_CONFIG_HOME, XDG_STATE_HOME and XDG_CACHE_HOME select the corresponding roots; use absolute paths. XDG_RUNTIME_DIR selects the MCP runtime location. Review files, agent working folders and worktrees have their own global and per-repository location settings. RADAR_CLAUDE_SDK_DIR can also override the SDK cache destination.

The config file holds a token if you typed one in. Otherwise it holds where the token is: env:GITLAB_TOKEN, or glab for the GitLab CLI’s login.

Service caches contain descriptions, comments and message text returned by their services. They also hold local state that a fresh remote sync cannot reconstruct: Slack read marks and review checkpoints, queued automatic reviews and their source context, session IDs/cursors, review records, and pending Work changes. The session metadata records working folder, title, provider, model and resume cursor; radar does not persist the dock’s full conversation timeline in that session metadata.

Ordinary action events store bounded operation metadata and scoped subjects rather than full service responses or conversation transcripts. Work’s authored titles and group labels are stored text in the same journal database, together with source bindings and relations. Paths, identifiers and labels still describe your work. The cache and journal databases are private files (0600); they are not encrypted. The diagnostic logger redacts registered secrets and recognized credential patterns before writing.

Older installations may also have per-part JSON cache files and .json.imported backups. Radar imports old caches into SQLite; if SQLite cannot be opened, it can fall back to the JSON files. Keep these in mind when backing up or removing local data.

What can be regenerated, and what cannot

Close all radar hosts before backing up or removing their state. Preserve SQLite databases together with any -wal and -shm companion files still present; do not remove an active process’s socket or database files.

Back up the journal, caches, configuration and the actual configured notes/review folders if you want to preserve your workspace. Deleting radar’s session pointers does not delete the provider’s own transcripts. Deleting local files also does not undo comments, merges or other writes already made to a service.