Patch

A desktop AI coding assistant. Open a project folder, describe a task, and Patch reads the code, edits files, runs commands and checks its work, asking for your approval before it changes anything.

Patch is a from-scratch TypeScript desktop coding assistant. CHANGELOG.md tracks the unreleased baseline using Keep a Changelog.

Repository: https://github.com/PierrunoYT/patch

The application and installer are named Patch (Patch.exe and Patch-Installer.exe on Windows). The default profile directory is Patch under the system application-data directory. Environment variables use the PATCH_* prefix. Existing profiles are not migrated automatically: set PATCH_USER_DATA to an existing profile folder to reuse its settings, keys and chats. The installer uses the patch application ID and does not upgrade installations with a different ID.

Features

• OpenCode Desktop-inspired interface with neutral light/dark themes, project and session navigation, a collapsible sidebar, and a single row of model, approval, plan and message controls below the prompt
• Chat with Claude (Opus 5.5 by default, Fable 5.1, Sonnet 5.5, Haiku 5.5), OpenAI GPT-6 (Astra, Sol, Luna), GPT-6.1 Sol or any OpenAI-compatible endpoint, with streaming answers; legacy Haiku 4.5 and GPT-6 Sol ids retain their compatibility and price estimates, and Claude can also go through a proxy or gateway (Settings → Claude base URL)
• Works directly in your project: read, search, edit and create files, run commands
• Claude Code chats: pick a claude-code/… model (or Claude Code's default) and the chat runs in your installed Claude Code CLI, with its own tools, your Claude Code settings and MCP servers, and compaction (a project's own Claude Code settings are not used; its CLAUDE.md and AGENTS.md are passed on as instructions). Patch shows what it does as usual, and its approval cards answer Claude Code's permission prompts. Claude Code keeps the chat history in its own session files; the saved chat keeps the transcript. Patch's own tools, permission rules, file backups and Undo, secret redaction and prompt-cache keep-alive do not apply to these tools (see Privacy and security)
• Windows sandbox permissions recover on the next helper startup after a forced stop; cleanup leaves live commands and unrelated container permissions intact
• Official Windows Node installations with missing AppContainer permissions work through narrow read-only toolchain grants or a private per-command copy, without administrator setup; package-readable Git/Python installations are left unchanged
• File replacements on supported Claude models use strict tool inputs to prevent omitted required fields in batched edits; every edit still validates locally and follows the approval rules
• Every file change and command is shown first (diffs, command text) and waits for Approve or Decline — or switch to Auto mode
• Decline with a note ("use pnpm instead") and the assistant adjusts
• Optional Plan mode: before multi-step changes, the assistant shows its plan as an approval card, also in Auto mode, and edits and commands ask until a plan is approved; the latest app mode note stays in effect across tool results and screenshots until another mode note changes it
• Undo on the card of any approved file edit or patch puts the files back (or deletes files the assistant created), as long as they are still as the edit left them; the assistant is told and has to read them again
• Semantic code search over the project (needs an OpenRouter key: files are embedded with Voyage voyage-code-4 and results reranked with Voyage rerank-3, both through OpenRouter; the key can be added mid-chat; credential files such as .env, keys, .npmrc and .envrc are never indexed, and secrets in other files are masked before upload); Settings shows whether the project is indexed (with progress while it builds) and can reindex it
• Built-in browser the assistant uses to check web apps: console output and screenshots
• Interactive terminal and a Git panel next to the chat: changed files with line counts, a hunk-by-hunk diff preview, discard (one file or all), AI-written commit messages (Generate), and Commit & Push
• Mention project files with @ in the message box; tool calls in the chat show how long they took
• Web search (Google Custom Search) and page fetching (long pages come in parts, fetched pages are cached for 15 minutes, and an objective lists the relevant lines first)
• Model Context Protocol (MCP) servers: add them in Settings (stdio programs or Streamable HTTP endpoints) and their tools are offered to the assistant; every MCP tool call asks for approval, also in Auto mode, and the card shows the call's arguments; a server that stops on its own is started again a few times
• Read-only subagents with their own context: task for broad questions such as "find every caller", finder (a cheaper model) to locate code and oracle for a second opinion on a hard problem. Settings can run task on a smaller model and lower the effort for finder and task; the small Claude model is Haiku 5.5 and the mid OpenAI model is GPT-6.1 Sol, while the settings defaults still match the chat. Their progress shows while they work, and independent read-only tool calls (including subagents) run in parallel
• Multi-file edits in one approval with apply_patch (Codex patch format, validated before writing), file search by name with glob, find_definition and find_references to jump to where a symbol is declared and list its uses without the comments and strings a grep also hits, and a todo_list checklist the assistant keeps while it works through a multi-step task
• Secrets are hidden from the model: private keys, cloud and Git host tokens, JWTs and credential values in tool results (an .env file, a printed token) are replaced by [REDACTED:_____] before the model, the transcript or the saved chat see them
• Edits to protected files (.env, keys, .git, editor and agent config, the project's AGENTS.md or CLAUDE.md and .patch skills folder, .mcp.json, .envrc, .husky/ hooks, shell start-up files, databases) always ask, even in Auto mode; case variants and Windows short names cannot bypass the check, and a failed safety check asks rather than allowing the edit
• Sandboxed commands refuse volume roots, your home folder or its ancestors, and roots overlapping application data or the installed app. Open a narrower project or explicitly approve an unsandboxed run. macOS command temp files stay inside the project; tools that insist on system temp need explicit unsandboxed approval.
• File reads, edits, patch writes/deletes and Undo use a bundled native helper that refuses symlink/junction targets and hard-linked writes. It holds file/directory handles and checks expected bytes before changing files, so a background command cannot redirect an edit by replacing a parent with a link. A missing helper refuses the operation; it never falls back to host pathname writes.
• Permission rules in Settings (JSON): allow, reject, always ask or hand a tool call to your own program, matched by glob on the tool name and its input (for example reject git push*)
• Project memory: the assistant can propose short notes about a project ("use pnpm, not npm"); you approve the exact text, and approved notes go into new chats. Kept in the app's data, not in the repository; switch off or edit in Project settings
• Project skills: Markdown instructions for recurring tasks in .patch/skills/, which the assistant loads when a task matches
• Long chats are handled by server-side compaction (current Claude models), and Compact chat (header button) summarizes older turns on demand; custom endpoints must support structured-output summaries using the chat's model. The status bar shows the latest request's prompt size, not the sum across Claude continuations. The full history stays in the saved chat
• Rate limits (429), server errors (5xx) and dropped connections are retried automatically, up to 4 times, waiting about 2 to 16 seconds or as long as the provider asks (up to a minute); each retry is shown in the chat and Stop works during the wait
• Failed or stopped Claude continuations after a server-side pause or compaction leave saved model history unchanged; retries start from the history before that attempt
• Stop a running task, including its project's background commands, and use Resume to continue it after cancellation settles, including after reopening the saved chat; the model is instructed to check interrupted actions before retrying them. A task cut off by a crash, whether during a model request or while tools were running, can be resumed the same way
• Keep several projects open in the sidebar, each with its own chat and unsent draft. Stop the current task before switching; one agent run is active at a time
• Same-project chat navigation keeps the interactive terminal and unfinished Git commit message. Clicking the active project tab or closing another project's tab also preserves expanded transcript sections; switching to a different project still resets the panels.
• Chats are saved automatically, listed by day in a sidebar, and can be searched by title, project or message text, and exported as Markdown (download button in the header); per-project custom instructions
• If a saved chat cannot be restored because its provider credentials are missing, Patch reports the error without switching projects or closing your current chat. Subsequent messages still work in the project shown in the UI.
• AGENTS.md (or CLAUDE.md) in the project root is always added to the chat's instructions; the status bar shows "AGENTS.md"
• Image attachments (attach or paste) for models that accept images, with a compact paperclip beside the model and mode controls; attachment chips take space only when present. The paperclip and paste are disabled for a Claude model id the app does not know to accept images (entered under Other model id…)
• The composer model picker groups Claude, OpenAI and Claude Code models in a themed menu above the input; use arrow keys to move between models, Enter to choose one, or Escape to close it. It locks after the chat begins.
• Token totals and estimated cost for the built-in Claude and GPT-6 models, including cache reads and writes, in the status bar (with how full the model's context window is), and each chat's estimated cost in the chat list and history; custom endpoints have no official-price estimate
• Prompt caching tuned for agent loops: the fixed tools and system prompt are cached once and reused, also by subagents on the chat's model, and an optional setting keeps an idle Claude chat's cache warm for up to an hour so a reply after a pause does not write the whole chat again (see PERFORMANCE.md for what it saved)

Getting started

Requirements: Node.js 22.12+ (22.x, 24.x or 26+, as Electron and Vitest need), Git (optional, for the Git panel). Claude Code chats also need the Claude Code CLI installed (Patch does not bundle it; on Windows, the native installer's claude.exe), and on Windows Git for Windows, whose Git Bash Claude Code uses.

npm install
npm start

Then:

1. File → Open Project… and pick a folder.
2. Open Settings (gear icon, Ctrl+,) and add your Anthropic API key. For official OpenAI models, add an OpenAI API key or press Sign in with ChatGPT. Code search needs an OpenRouter key. Add a Google API key and search engine id for web search.
3. Describe a task, e.g. "Add input validation to the signup form and a test for it."

For a Claude Code chat, sign in to Claude Code once with claude in a terminal. Settings → Claude Code lets you choose the Claude Code program as an absolute path; leave it empty for detection on PATH or in the usual install folder. A path that is relative or does not exist is refused. Claude Code uses its own sign-in by default. Give Claude Code my Anthropic API key is off by default; when on, Claude Code gets the saved key and the Claude base URL from Settings, and those chats are billed to that key.

ChatGPT subscription chats use the Codex backend and omit the unsupported truncation parameter. API-key chats on the OpenAI Responses API retain automatic truncation.

Recent projects are ordered by the latest open, including folders opened within the same millisecond.

To build an installer: npm run dist (on Windows, dist/Patch-Installer.exe; the unpacked app is dist/win-unpacked/Patch.exe; a DMG on macOS; an AppImage and deb on Linux, where the deb installs the command patch-app). Local pack and dist commands never publish; releases are published by the tag-triggered release workflow. The Windows installer is the supported download. Linux and macOS packages are built by CI so they can be tried, but they are experimental. CI starts the installed Linux deb, the AppImage and the macOS app from its DMG and checks they open a project, run a terminal command and approve a file edit; the deb and the AppImage also passed that check in Ubuntu 24.04 under WSL. On Linux, prefer the deb: where user namespaces are restricted (Ubuntu 23.10 and later, through AppArmor) the AppImage starts without Chromium's sandbox, and Patch shows a warning when that happens; the deb installs an AppArmor profile or the setuid sandbox helper instead. Nobody has used the packages on a real desktop yet, and a downloaded copy of the unsigned macOS app has not been tried.

Packages include only the application output in out/main, out/preload and out/renderer, excluding test logs and scratch files. If an older Windows build exits immediately with ASAR Integrity Violation, rebuild and reinstall it; do not disable the integrity check. Your profile, settings and chats are separate from the installation.

For development in Amp orbs, the repository includes setup and resume scripts to prepare and reuse dependencies. See orb setup for requirements and headless test commands, and sandbox test prerequisites for native helper, Ubuntu AppArmor and CI-only Windows null-device setup. Windows unit files run serially; explicit concurrency tests still overlap commands. Restart tests use platform-specific encryption persistence checks and deterministic unreadable-key fixtures.

To verify a download, compare its hash with SHA256SUMS.txt from the same release (sha256sum -c SHA256SUMS.txt, or Get-FileHash .\Patch-Installer.exe on Windows). Signed Windows releases also show a valid publisher under the file's Properties, Digital Signatures tab. Patch has no update check, so reinstall from the latest release to get security fixes.

Keyboard shortcuts

Shortcut	Action
Enter / Shift+Enter	Send / new line
Ctrl+O	Open project
Ctrl+N	New chat
Ctrl+.	Stop the assistant
Ctrl+,	Settings

(Cmd instead of Ctrl on macOS.)

Privacy and security

• The app talks only to the APIs you configure (Anthropic or your Claude base URL, OpenAI or your OpenAI-compatible endpoint, Google search), to OpenAI sign-in and the Codex backend at chatgpt.com when you use Sign in with ChatGPT, and to pages you or the assistant open. There is no telemetry and no update check. Crashes and other app errors are written to a log file in the app's data folder (logs/app.log.jsonl) for your own troubleshooting, along with a line per start giving the app and Electron version and platform. Native Electron crashes are saved locally as minidumps and added to that log on the next start; reports are never uploaded. Chat/provider error text shown in the conversation is not copied to the log; other error messages and stacks can mention file paths, but the log does not contain your chat history. Recognized API-key and token formats, including Groq (gsk_…), xAI (xai-…), JWTs, private keys and passwords in URLs, are redacted from new messages and stacks; review logs before sharing because arbitrary secret formats may not be recognized. Help → Show Log Folder opens it.
• To make Undo possible, the previous version of every file the assistant edits is copied to the app's data folder (edit-backups, the latest 50 edits per chat, deleted with the chat). Those copies are not encrypted; delete the chat if a project contains secrets you do not want copied.
• API keys, MCP server credentials, and the ChatGPT access and refresh tokens from Sign in with ChatGPT are encrypted with the operating system's keychain (Electron safeStorage) when available (on Linux this needs a keyring: Electron's basic_text fallback counts as no encryption) and never reach the UI process. Settings shows whether a ChatGPT account is signed in, and the account email when the login provides one. It does not show the tokens. Without system encryption, saving any of these secrets asks you to confirm plaintext storage and Settings warns; cancelling leaves them unsaved. Existing plaintext secrets are migrated when encryption becomes available; failed migration keeps the warning and preserves them.
• The assistant's file access is confined to the open project folder, including through links: a file is checked where it would really be written, even when it does not exist yet. Commands can still damage the writable project — keep Ask first mode on unless you trust the task. In Settings, "Commands allowed without asking" lists commands (one per line, for example npm test) that skip the approval card in Ask first mode; a line also allows the command with arguments, except arguments that write a file or run another program (--output, -o/-O also in a group of short flags such as curl -so, --exec, find -exec/-delete, --in-place …), which still ask, however they are quoted or escaped. Project settings… in the project menu has the same two lists for one project, added to the global ones; they are kept with the app's data, not in the project, so a repository cannot allow its own commands. The same dialog has a Check after edits command (for example npx tsc --noEmit -p .): with the sandbox on, Patch runs it after each batch of file edits and tells the assistant the errors in the edited files, or new since the last check. When the sandbox is off, Patch skips the automatic check and tells the assistant to run it manually rather than running edited code with host rights without a command approval. Commands containing ;, &, |, >, <, a backtick, $, (, ), {, } or a line break are always asked about (PowerShell, which runs the commands on Windows, runs (...) and {...} even inside a program's arguments), and file edits always wait for you. Only allow commands you would run yourself: npm run would let the assistant run any script in package.json.
• Tool results pass through secret redaction before the model sees them, and write_file, edit_file and apply_patch refuse text that contains the [REDACTED:_____] placeholder. Redaction recognises well-known token formats, passwords in connection-string URLs, credential-named values and the exact API keys you saved in Settings; it is not a guarantee, so keep secrets out of projects you do not trust the model with.
• File edits require valid UTF-8: edit_file, write_file overwrites and apply_patch updates (including moves) reject other encodings before approval and check again before writing. Convert legacy files to UTF-8 explicitly first; the tools never guess an encoding or silently replace invalid bytes.
• Permission rules (Settings → "Permission rules (JSON)") decide a tool call before the normal approval: allow, reject, ask (also in Auto mode) or delegate (a program you name answers). Per-call safety checks for protected files and sandbox escalation still require approval after an allow decision. Saving an allow or delegate rule asks for confirmation, like switching to Auto mode. Removing or changing an existing ask, reject or delegate rule, or changing rules preceding it, also needs confirmation because the first matching rule wins. Rules see a path relative to the project (without regard to case on Windows and macOS), every file an apply_patch touches (also as edit_file), and each part of a command between shell operators; the strictest answer wins. Cancelling leaves settings unchanged. A delegate program runs with your permissions.
• Agent shell commands (run_command, background ones included) run in a sandbox by default: bubblewrap on Linux, Seatbelt (sandbox-exec) on macOS and an AppContainer on Windows (through the bundled sandbox-helper.exe), or, on any platform with Settings → Command sandbox → container, a Docker or Podman container. Only the project and temporary folders are writable, the rest of your home folder is hidden, and the network is off unless the setting or a one-time approval allows it. On Windows, a sandboxed command sees the project as the root of a temporary drive letter, taken from Z: down to D:, so relative paths are portable while the original absolute project path may be inaccessible. Each project mapping is journaled before creation; the next helper startup reclaims it after a crash, preserving live runs and drive letters reused for other folders. The project's write permission is granted to a per-project sandbox identity the first time a command runs there and kept until you close or remove the project in Patch, so later commands start in a fraction of a second even with a large node_modules. Credential-looking environment variables are removed as well. Automatic and container modes refuse to run when their backend is unavailable; they never silently fall back to your full rights. The agent can request unsandboxed access for one run, or, narrower, read-only (read_paths) or read/write (write_paths) access to a few existing paths outside the project while the command stays sandboxed (#126). The approval card shows the resolved paths, a path grant always asks (even in Auto mode or with an allow rule), covers only that command and what it starts, and never turns on the network. Explicit network/unsandboxed requests and URL-triggered network grants always require approval, even in Auto mode or with an allow permission rule. On Linux and Windows the sandbox network allow-list is enforced: commands reach only the listed hosts through a filtering proxy, and a tunnel carries only TLS that names the listed host (on Windows, local services on the loopback address stay reachable). On macOS and in containers it requests unrestricted network access, not hostname filtering. The terminal panel is not sandboxed, and MCP servers only when you set "sandbox": true on one (Linux and Windows). npm run test:sandbox exercises real backends when available: Linux bubblewrap and Docker isolation probes have passed in an orb, and Windows has a real-helper integration suite. macOS and Windows checks need their native hosts; unavailable backends skip explicitly. See sandbox test prerequisites. Program Files PATH toolchains that lack package access get a read-only copy, made once per install version and reused; the shared install folder itself is never opened to the sandbox (#207). The copy is made once per installed version and kept in %LOCALAPPDATA%\Patch\sandbox-toolchains\cache, readable only by Patch's sandboxed commands, so later commands start in about 0.3 s instead of copying again; an upgrade makes a new copy, and copies go once replaced or unused for 30 days. No grant opens all of Program Files. Copies are bounded to 5,000 entries and 256 MiB per command, with a 30-second copy limit; unsafe links or failed preparation refuse execution. Staging redirects PATH and directly launched executables, not absolute paths embedded in shell text. Already package-readable toolchains need no extra grant or copy. Treat sandboxing as a second line of defence and still use Ask first mode, or a VM or separate account, for untrusted repositories.
• Claude Code chats run the Claude Code program with your rights, outside Patch's command sandbox and file confinement. On native Windows, Claude Code's commands run unsandboxed, because Windows has no sandbox for them. On macOS, Linux and WSL2, Claude Code's own Bash sandbox applies as your Claude Code settings configure it; Patch does not force, change or add to it, and it is not a sandbox around the whole app. Claude Code loads your own Claude Code settings, hooks, CLAUDE.md and MCP servers, but not the project's: a repository's .claude/settings.json, .claude/settings.local.json and .mcp.json are ignored, because a Patch chat never shows Claude Code's workspace-trust prompt, and a cloned repository's hooks would otherwise run commands and its allow rules skip the approval cards (#270). The project's AGENTS.md and CLAUDE.md (root only) are passed to Claude Code as instructions instead. Its tools are not Patch's: Patch's path checks, protected-file prompts, secret redaction and Undo do not apply to them. Patch always asks before an MCP tool call, before Claude Code leaves plan mode and before a Bash call that asks to run outside Claude Code's sandbox, even in Auto mode; other calls ask only when Claude Code's own rules would ask. Auto mode allows the rest, but not before a plan is approved in plan mode. Claude Code's session files, with the conversation's history, are kept in its own configuration folder, and a stopped run is interrupted before the next message.
• The UI runs sandboxed without Node.js access; model Markdown is sanitized as HTML-only before display. SVG (including images and filter images), MathML, images, embeds, forms and styles are removed, and so are class (except code highlighting), id and hidden, so a reply cannot borrow the app's styling. Markup inside code blocks remains visible as text.
• The macOS command-sandbox policy uses exact Mach service names, not blanket lookup: CLI user/group lookup, plus DNS/certificate-trust services only with network access. LaunchServices, URL-session and preferences daemons stay excluded even with network access. Arbitrary POSIX shared memory is not granted (named semaphores are, for Python multiprocessing). Commands get no pseudo-terminal and cannot open other terminals' ttys (Terminal tabs, the terminal panel), so programs that open their own pty (script, expect) need an unsandboxed run (#232). System information reads are limited to named entries, but Seatbelt cannot hide other processes from ps-style queries. These restrictions do not sandbox the interactive terminal or MCP servers. Native macOS regressions use harmless fixtures and unsandboxed controls; a Windows test run cannot validate Seatbelt enforcement.
• Native sandbox commands inherit only allow-listed runtime/toolchain location variables and, on Unix, locale settings. Patch sets home/temp paths deliberately; arbitrary host values (including DATABASE_URL), credential-agent/display handles and runtime injection/startup options are not inherited by default. This boundary is separate from output redaction. Settings can grant additional host variable names or override the native sandbox PATH, with native confirmation; granted values may be private and become visible to commands and the model. Known startup/injection variables and agent/display handles stay blocked. Container commands still receive only their explicitly configured environment, and these settings do not apply to containers. The interactive terminal is unchanged; explicitly approved unsandboxed agent commands retain the older credential-name filter and can inherit other private values.
• Windows sandbox shells load the built-in PowerShell Management and Utility modules directly from the installation folder, so standard file and output cmdlets remain available without relying on automatic discovery or inheriting user module paths.
• Windows sandbox commands use a private per-command temp folder and npm cache, plus an empty npm user config; the host temp/cache and profile config stay hidden. Project PATH entries use the mapped project drive, including entries spelled with 8.3 short names, and sandboxed PowerShell uses a process-only execution policy so npm.ps1 can start. Node versions with libuv older than 1.53 (as of October 2026, every Node release) still hang on ordinary node --test because of an upstream AppContainer pipe bug (#101). node --test --test-isolation=none or npm test -- --test-isolation=none works on Node versions supporting that flag, but runs test files together instead of in separate processes. Patch never applies that workaround automatically; when a Windows sandbox command times out, its result tells the agent about the workaround and about requesting an unsandboxed run.
• Browser guests are sandboxed without Node.js or a preload. The main process accepts only the Browser panel's two session partitions: persist:browser for your own browsing and the in-memory agent-browser for pages the agent opens, so the agent never uses your cookies or sign-ins. Guests requesting the app's default session or another partition are rejected.
• This source baseline uses Electron 44.5.1, including upstream ANGLE, Chromium, Dawn and V8 fixes. Existing installations need a rebuilt installer to receive runtime updates; Patch does not update itself.
• The selected repository's entire Git metadata is read-only inside command sandboxes, preventing planted configuration, hooks and other control metadata. Non-Git folders run too: Patch leaves a protected .git reservation file without initializing a repository. Git refuses the folder while it exists ("invalid gitfile format"), so a bare repository a command plants in the project folder is never used (#129); Initialize in the Git panel removes it, or delete it before running git init yourself. A project inside another repository keeps an empty .git folder so Git still finds that repository, plus a protected empty HEAD folder so Git never accepts the project folder as a planted bare repository (#132). Husky, active hooks and existing command overrides are accepted. In-project gitfiles/shared metadata protect both the pointer and the top-level metadata directories; external metadata, linked/special files and config includes outside protected directories still refuse execution. Project edits and Git reads still work; Git writes need the Git panel or explicit unsandboxed approval, which removes filesystem confinement and permits unrestricted network access. The Git panel refuses implicit bare-repository discovery in writable project files. Existing host Git integrations can still execute writable project code: a hook that runs npm test runs whatever the agent left, just as running npm test yourself would. The Git panel refuses Push and Commit when the repository's own config would run a project file as a credential helper, SSH/askpass command, local receive/upload-pack or signing program (#130). See command sandbox limitations.
• The project's existing top-level editor, agent and CI configuration is read-only inside command sandboxes as well (.vscode, .idea, .claude, .cursor, .agents, .patch, .husky, .github, .mcp.json, AGENTS.md, CLAUDE.md, .envrc and similar), so a command cannot plant a task, MCP server, hook or workflow that runs outside the sandbox later (#127). An entry that does not exist yet cannot be guarded while the command runs, so one that appeared while it ran is moved aside to <name>.patch-quarantine-<time> when it ends, where nothing reads it, and the output says so (#262). Nothing is deleted, since the user or an editor may have created it, and an entry Patch's own edit tools wrote to meanwhile stays in place with a note (#276).
• macOS packaging enables the hardened runtime with only the JIT entitlement for the app and its helpers; it does not grant DYLD library injection or unrestricted executable memory. Signed packaged launches still need verification on a Mac; Windows remains the supported platform.
• The Windows release workflow refuses unsigned or invalidly signed app and installer builds, and publishes SHA-256 checksums. Releases are blocked until the maintainer provisions signing credentials; local development builds may be unsigned.
• In Ask first mode, page fetching and browser tools require approval unless their exact hostname is listed in Settings → "Network hosts allowed without asking". The list starts empty and does not include subdomains automatically. Cross-host redirects require a separate tool call; browser popups are denied. Auto mode skips tool approvals, except for MCP tools and Plan mode, which always ask. This is not a network sandbox: a public page in the agent's browser cannot load from local or private addresses (including names that resolve to one; its connections go through a local proxy that checks each one and dials only the address it checked, so DNS rebinding cannot switch them), and the agent's browser has no network while it shows a project file, but other subresources and Google search are not filtered, and approved hosts may receive private data. Avoid untrusted pages in projects with secrets.
• MCP servers you add run with your permissions (a stdio server is a program on your computer), unless you set "sandbox": true on a stdio server (Linux and Windows); their environment variables and HTTP headers are encrypted like API keys and never reach the UI.
• Sandboxes open only the binary/cache subdirectories of Cargo, Maven and Gradle, not their credential-bearing parent folders; global Git configuration is hidden too. Commands that depend on those private settings need explicit unsandboxed approval. This does not hide secrets stored inside the project itself.
• The Git panel disables hooks (including core.hooksPath overrides), core.fsmonitor, repository-defined clean/smudge filters and external diff drivers, and does not look inside submodules, whose own config could name filters. This prevents an agent from planting a hook in the project and having the panel execute it outside the sandbox. Use the terminal to run Git with trusted hooks, including Git LFS pre-push hooks. Open security findings carry the security label.

Details in docs/ARCHITECTURE.md.

Documentation

Settings, Git changes, and browser preview

• User guide — approvals, plan mode, allow-lists, project skills, MCP servers, the research subagent, stop and resume, chat history and export
• Architecture — processes, IPC contract, agent loop, providers, tools, storage, security model
• Development guide — setup, scripts, tests, where to change things; validation workflow explains focused iteration and full checks without duplicate unit runs
• Performance — long-chat measurements and what was changed
• Windows sandboxing research — outside developments (Microsoft Execution Containers, the OS process security environment, libuv for node --test) and how they relate to open issues
• Contributing
• Issues — open work, bugs and ideas
• AGENTS.md — guidance for AI coding agents working on this repo

License

Copyright (c) 2026 PierrunoYT.

Patch is licensed under the Apache License, Version 2.0 (Apache-2.0). You may use, modify and redistribute it, including commercially and in closed-source products, subject to the license's conditions. Distributions must include the license and retain required notices; modified files must carry prominent change notices. Apache-2.0 includes an explicit contributor patent grant with patent-litigation termination provisions and does not grant trademark rights, except for the limited uses stated in the license. The software is provided on an "AS IS" basis, without warranties or conditions of any kind.

The switch to Apache-2.0 takes effect with this licensing change. Previously released MIT versions and material retain their MIT permissions; the original notice is preserved at the end of LICENSE. That historical notice does not offer new Apache-only contributions under MIT. Third-party dependencies retain their own licenses. Using Patch to create or edit an independent project does not change that project's license.

See distribution guidance before sharing a build.