Security model

What this covers

OpenOrc runs coding agents with your account's access to your computer. This page covers who else could try to use that access, and what stops them:

• Agents do what the conversation's mode allows. The rules are on Permissions and app tools.
• Web pages, in your browser or in the Preview, cannot reach OpenOrc's local servers or the app's own interface.
• Other accounts on the same computer cannot read the secret addresses OpenOrc gives agents.
• Other programs running as you cannot start OpenOrc in a way that runs their code inside the app, drives its window, or makes it start agents or approve requests on its own.

A program that already runs as you can read your files, including OpenOrc's, and can choose the environment OpenOrc starts with. What OpenOrc cannot protect against lists what follows from that.

Local servers

Agents reach OpenOrc's tools through its MCP server. It listens on 127.0.0.1 on a random port, so other computers cannot connect to it. Each agent process gets its own address:

http://127.0.0.1:<port>/mcp/<random UUID without dashes>

• The address is the only credential, and it belongs to one run. A call through it acts for that run and follows that run's mode.
• It works only while the run's process is running. When the run ends, OpenOrc deletes it, so a copy left in a file or a log no longer works.
• A request that carries an Origin header, or names any host other than 127.0.0.1:<port>, is refused. Agent CLIs send neither, and every web page does, including one that points its own domain name at your computer.
• The address never appears on a command line, which every account on the computer can list. Claude Code reads it from a file only you can read, deleted when its process closes. Codex and OpenCode receive it over the process's standard input.

The same address answers Claude Code's file check in Plan and Accept edits: for each file edit, the hook sends Claude Code's whole request, including the edit's content, to <address>/file-boundary with curl, and OpenOrc answers from the real path. See Claude Code.

Other servers also listen on 127.0.0.1. The MCP Apps sandbox serves each interface from an MCP server at its own random path, on its own port, so it runs apart from the app. The team relay requires a device key on every request and refuses requests with an Origin header. On macOS, while a downloaded app update waits to be installed, the update library also serves it to the system installer from 127.0.0.1, on a random port and behind a random password.

Source: packages/mcp/src/index.ts, packages/mcp/src/file-boundary.ts, apps/desktop/src/main/mcp-app-sandbox.ts

The app window and the Preview

The interface runs in a sandboxed Chromium page with context isolation and no Node.js. It reaches the rest of OpenOrc only through a fixed set of functions and one validated message channel to the core. See Processes and messaging.

• The window loads only the files that ship with OpenOrc and never navigates away from them. Embedded <webview> tags are refused.
• A web link opens in the Preview or in your browser. Files and other schemes do not open, and only the app's own page can ask to open a link.
• The app may show notifications and copy text to the clipboard. Every other web permission, such as the camera, microphone, or location, is refused, and so is any request from another page or frame.

The Preview is a separate sandboxed page with its own storage. It is refused every web permission, cannot download files, and cannot open windows. Because it keeps the sessions you sign in to there, typing and clicking in it follow the mode; see The browser Preview.

Source: apps/desktop/src/main/app-origin.ts, apps/desktop/src/main/index.ts, apps/desktop/src/main/browser-pane.ts

The installed app

Electron has switches that let any program run code as the app, and on macOS the system attributes that code to the app, with the access you gave it. OpenOrc turns them off with Electron's fuses, flags written into the app's binary when it is built:

RunAsNode                              off
EnableNodeOptionsEnvironmentVariable   off
EnableNodeCliInspectArguments          off
EnableCookieEncryption                 on
EnableEmbeddedAsarIntegrityValidation  on
OnlyLoadAppFromAsar                    on

• The app itself cannot be started as plain Node.js, and ignores NODE_OPTIONS and --inspect.
• It loads its code only from its app.asar archive. The build records the archive's SHA-256 in the app, on macOS in the signed Info.plist, and Electron checks it before loading.
• Cookies, including the Preview's signed-in sessions, are encrypted on disk with a key kept in the macOS Keychain or protected by Windows DPAPI.
• An installed app refuses to start with --remote-debugging-port or --remote-debugging-pipe, before it opens a window or a debugging port.
• Release builds contain no test automation: nothing that starts agents, approves requests, runs benchmarks, or takes screenshots, and no diagnostics screen. These exist only in development and test builds, so no environment variable can make an installed app start work or approve a request on its own.

On macOS the app runs with the hardened runtime and one entitlement, com.apple.security.cs.allow-jit, which V8 needs to compile JavaScript. Library validation stays on: the app loads only native code signed by Apple or by the same developer, and all of its own native code sits outside the archive, where signing covers it.

Before a release is published, a check runs on the signed macOS app and the installed Windows app. It reads the fuses, looks for native code inside the archive and, on macOS, for any executable file not signed by the same team, starts the app, and confirms that ELECTRON_RUN_AS_NODE, --inspect, and remote debugging do nothing.

Source: apps/desktop/electron-builder.yml, apps/desktop/build/entitlements.mac.plist, scripts/packaged-release-check.cjs

Secrets and your data

• Slack tokens and the optional memory API key are encrypted with Electron's safeStorage, which uses the macOS Keychain or Windows DPAPI, and written to files only you can read. They are never in the database. See Settings and secrets.
• OpenOrc never reads or stores the agents' logins. Each CLI signs in and keeps its credentials itself.
• Text that looks like a secret is replaced before it is stored. See Redaction.
• The database is a plain SQLite file in your profile folder, and it is not encrypted. Your conversations, plans, and memories are as private as the rest of your files.
• Conversation titles and memory summaries made with Claude Code pass their prompt on the command line, which every account on the computer can list while it runs. The prompt holds up to 1,500 characters each of a conversation's first message and reply, or a run's digest of up to 12,000 characters with its title and task spec. Codex and OpenCode receive these prompts over standard input. See Background requests through agents.

What OpenOrc cannot protect against

• Programs that run as you. They can read OpenOrc's database, its log files, and the files that hold the running agents' addresses, and they can call those addresses while the runs last. Encrypted secrets stay protected by the Keychain or DPAPI.
• Your shell's startup files. OpenOrc starts your login shell to find the agents and their environment, and the terminal panels run your shell. A program that changes those files changes what runs there.
• The environment OpenOrc starts with. Terminal panels run the shell named in the environment OpenOrc was started with (SHELL, or COMSPEC on Windows), and agents inherit that environment, including variables such as NODE_OPTIONS. A program that starts OpenOrc with its own variables can get its code run by a terminal or an agent.
• Access you grant on macOS. Agents and terminal shells started by OpenOrc share the privacy access you give OpenOrc, such as Documents, Desktop, or Full Disk Access. The fuses stop other programs from running their code inside OpenOrc itself. They do not stop code that reaches a terminal or an agent through the files and variables above, or a request that asks an agent to use that access.
• What agents are allowed to do. In Autonomous mode, an agent's commands run without asking, with your account's access. Choose the mode for the work.

Reporting a vulnerability

Report suspected vulnerabilities privately through GitHub: on the repository page, open the Security and quality tab and click Report a vulnerability. Please do not post details in a public issue. SECURITY.md lists what to include.