Security model

diri is a local developer tool that launches other powerful developer tools. It helps you avoid orchestration mistakes. It is not a sandbox.

#What agents can do

Shells, coding agents, hooks, MCP servers and browser automation run as your user. They can read any file your account and the operating system allow, use inherited environment variables and configured credentials, and reach the network. diri does not inspect or approve each action they take. Each agent's own permission settings still apply.

• Worktrees keep agents from editing the same files by accident. They are not a security boundary.
• For untrusted code, use a separate OS account, VM or container, with limited credentials and network access.
• Only run agents and MCP servers you trust.

#The Engine and its socket

The app, the CLI and agents talk to the background Engine over a Unix socket. The socket and state files are scoped to your user. Any process already running as your user is inside the same trust boundary and can drive diri.

The dirijor CLI acts with your full authority. It is a tool for you and your scripts.

#MCP authority and lineage

Agents that diri starts can use its MCP server to start and coordinate other agents. Writes through MCP are limited by where the calling agent sits in the session tree:

More rules:

• Every write needs a live diri session identity. A stale or unhosted MCP process is refused.
• An agent cannot target itself, and cannot stop the session waiting on its result.
• Worktree writes must stay inside the caller's project.
• Messages to a session outside the caller's own line are labelled with who sent them.
• A delegated agent can add only to the note it was started from, or to notes that mention it or one of its ancestors.
• Delegation is capped at 3 levels deep and 16 live children per session. Set DIRIJOR_MAX_SPAWN_DEPTH and DIRIJOR_MAX_LIVE_CHILDREN in diri's environment to change the caps.

Every tool and its arguments are in the MCP tool reference.

#Remote hosts

Remote sessions run under the account you connect as. diri relies on SSH for host verification, keys and encryption. It does not add its own relay or authorization layer.

• Prefer a dedicated non-admin account with narrowly scoped credentials.
• diri never runs sudo and never changes host-wide configuration.
• The remote helper is verified by length, SHA-256, build ID and protocol before use. Its folders are 0700, its files and sockets 0600.
• Your local environment, local sockets and credentials are not copied to the server.
• SSH password and host-key prompts are shown by a separate helper with no logging, so answers never reach diri's state or diagnostics.

Details are in Remote hosts.

#Secrets in terminals

Terminal replay logs and scrollback can contain prompts, output, paths and secrets a program printed. Treat them as sensitive.

A password typed at a prompt that turns echo off, such as sudo, ssh or read -s, is never echoed, so it never reaches the replay log, scrollback or exports. While a local session sits at such a prompt, diri does not use your typing to name the session, hides clipboard text in the paste review, and on macOS turns on Secure Keyboard Entry for that terminal. Remote sessions do not report this state yet. A program that reads a secret in raw mode and draws its own mask looks like any other full-screen program.

#Account credentials

Saved Claude and Codex logins are stored in owner-only files beside the Engine's state. They are never returned in responses, logged or passed as command-line arguments. See Accounts and usage.

#Updates

On macOS the updater downloads a versioned ZIP from GitHub Releases, checks its SHA-256 against the release feed, verifies the code signature, Team ID, bundle identifier and notarization, and refuses downgrades. Linux packages do not update in place. Each Linux release file has a Sigstore signature you can check with cosign verify-blob, as described in diri/LINUX.md.

#Diagnostics and privacy

diri has no account system and no advertising. It records diagnostics so bugs can be fixed from a report, and shares them with the project unless you turn sharing off.

Every diri process keeps a local log in ~/Library/Application Support/Dirijor/telemetry/spool, capped at 64 MiB.

Unless you turn sharing off, the Engine uploads the log about once an hour, or within a minute after a crash, to a Cloudflare Worker run by the project. Uploads carry a random install id, your short Support ID and a name, which defaults to your macOS login name. They are kept for 30 days and readable only by the maintainers.

#Your controls

Open Settings → General → Privacy:

To turn recording off entirely, set DIRI_TELEMETRY=off in diri's environment. Missing or unreadable privacy settings turn uploads off.

diri also connects to GitHub Releases for updates, and makes network connections when you use remote hosts, pull request monitoring, browser automation, or an agent that uses the network. diri does not proxy that traffic. The full policy is in PRIVACY.md.

#Report a vulnerability

Use GitHub private vulnerability reporting. Do not put exploits, private terminal output, tokens or personal paths in a public issue.

Include the diri and OS versions, a minimal reproduction, the impact you believe is possible, and any suggested fix. You should get an acknowledgement within seven days. Fixes go into the latest release.

In scope: permission-boundary bypasses, unsafe update or IPC behaviour, credential disclosure, session isolation failures and unintended remote execution. A tool doing something you explicitly allowed is not a diri vulnerability.