A local-first workspace for AI coding
Download · Run locally · Build from source · macOS signing
Sentinel is a desktop app for working with AI inside a real codebase.
It keeps the repo, the thread, the terminal, the browser, and the runtime in one place. Models, approvals, memory, automations, integrations, and repo state all stay close to the work too.
Open a workspace. Start a thread. Read code, plan something, make edits, run commands, inspect diffs, commit, push, open a PR, come back later, keep going.
Sentinel is still alpha.
Some parts are solid. Some parts are rough. Things will change.
Release builds are published on GitHub Releases:
- Download the latest release
- macOS builds are available as DMGs and need macOS 13 (Ventura) or later
- Windows builds are available as NSIS installers for 64-bit Windows 10 or later
- Linux builds are available as AppImages, DEBs, and RPMs for x64 and arm64 and need glibc 2.34 and libstdc++ from GCC 11 or newer (for example Ubuntu 22.04, Debian 12, Fedora 35, or RHEL 9)
Electron 44 dropped support for macOS 12, 32-bit Windows, and 32-bit ARM Linux, so Sentinel no longer ships for them. Copies already installed on macOS 12 keep working, but the in-app updater no longer offers them new versions.
If you want the current development version, run it locally from source.
The workspace is a real local folder. The thread is the main unit of work. Repo state matters. Longer tasks need more than a prompt box.
Each thread lives inside a workspace, and that workspace can point at a local project folder. From there the app can keep track of repo state, model state, approvals, checkpoints, worktrees, queued follow-ups, and the rest of the thread context without making you rebuild it every time.
A workspace points at a local project directory.
Inside that workspace, you start threads. A thread can be a normal chat or a plan. While you work, Sentinel keeps the thread close to the repo, the model, the runtime, the terminal, the diff, and the rest of the task context.
The shell stays around that work. The left side is for workspaces and threads. The center is the active thread. The bottom panel is the terminal. The right side is where diffs, PR state, browser tabs, and delegated runs show up.
The short version is simple: workspace, thread, chat or plan, edit, run, diff, commit, push, PR.
| Area | What it covers |
|---|---|
| Workspaces | Local project folders, thread history, workspace-level context |
| Threads | Chat mode, plan mode, queued follow-ups, checkpoints, long-running work |
| Repo workflow | Diffs, branches, worktrees, commits, push, PR flow |
| Built-in tools | Terminal, browser, attachments, voice input, approvals |
| AI setup | Ten engines with instances, providers, model selection, reasoning |
| Long-term context | Memory, context compaction, recurring automations |
| Extensibility | Skills, MCP servers, integrations |
sentinel is the built-in harness. It handles the app side of the run so the thread can keep its state over time.
The other engines are coding agents installed on your machine, carried inside the Sentinel shell. The runtime changes, but the thread still lives in Sentinel with the same workspace, repo panels, approvals, settings, and history around it.
| Engine | What it runs |
|---|---|
sentinel |
Sentinel's own engine, on the providers you connect |
claude |
Claude Code, through the Claude Agent SDK |
codex |
The Codex CLI, through its app server |
copilot |
GitHub Copilot, with the runtime bundled in Sentinel |
cursor |
Cursor Agent, over ACP |
opencode |
OpenCode 1.x or 2.x, through its local server |
grok |
Grok Build, over ACP (experimental) |
antigravity |
Google Antigravity's ACP server, installed by Sentinel (experimental) |
pi |
The Pi coding agent, over RPC (experimental) |
acp |
Agents from the ACP Registry, such as Devin, Gemini CLI, and Mistral Vibe (experimental) |
Settings → Engines installs and updates each agent, signs it in, shows its plan usage where the agent reports it, and lets you add more than one instance of an engine, each with its own binary, environment, and (for Claude, Codex, Copilot, and Grok) its own home directory. Permission modes and plan mode depend on the engine. See Engines by agent.
Sentinel refreshes its engine manifest (model metadata and supported CLI versions) and checks for newer CLI releases once an hour. Both can be turned off in Settings → Engines, or with SENTINEL_DISABLE_REMOTE_MANIFEST and SENTINEL_DISABLE_ENGINE_UPDATE_CHECKS.
The thread is carrying more than messages. It can also carry the current engine, model, working directory, queued follow-ups, repo checkpoint state, and runtime-linked session state.
Compaction is part of this too. Longer threads can tighten older context and keep moving without dragging every raw turn forward forever.
Workspaces map to local folders. Threads live inside those workspaces. You can pin them, archive them, switch between chat mode and plan mode, and come back later without losing the task state around the work.
The repo stays attached to the thread. Sentinel can inspect status, show diffs, create and switch branches, commit, push, open a PR, and isolate thread work in a worktree. It also keeps checkpoints tied to thread history, which helps once the work starts branching.
The rest of the app stays close to that thread. There is a built-in terminal, a built-in browser, file and document attachments, voice input, and approvals around tool use. For longer tasks, there is plan mode, queued follow-ups, memory, context compaction, and recurring automations.
Skills, MCP servers, and integrations sit around the same flow. They are separate systems because they do different jobs, but they still land back in the same workspace and thread model.
| Surface | Included |
|---|---|
| Core shell | Workspaces, threads, sidebars, command palette |
| Repo tools | Status, diffs, branches, worktrees, commits, PR flow, checkpoints |
| Execution | Terminal, approvals, runtime controls |
| Context | Plan mode, follow-ups, memory, context compaction |
| Inputs | File attachments, document loading, voice input |
| Extensions | Skills, MCP servers, integrations, automations |
The sentinel engine runs on the AI SDK (version 7) and supports OpenAI, Anthropic, Google AI Studio, Google Vertex AI, xAI, Azure OpenAI, Amazon Bedrock, Groq, Cohere, Moonshot AI, Mistral AI, DeepSeek, Ollama, OpenRouter, and Vercel AI Gateway.
Image and video generation also supports Black Forest Labs, Kling AI, ByteDance, Fal, and Replicate.
The app can connect to systems around the repo, depending on how you set it up. Current integrations include Gmail, Google Calendar, Google Drive, Slack, Notion, GitHub, Linear, Airtable, PostgreSQL, MySQL, MongoDB, Yahoo Finance, arXiv, and PubMed.
Some use OAuth. Some use connection config or API credentials. A few are authless.
Sentinel makes the most sense when the work is bigger than a one-off prompt.
It helps when the repo matters, when the thread needs to keep state over time, when you want plans, diffs, approvals, and commands in the same place, when you want local runtimes and local project context, and when you want recurring tasks or saved memory around the project.
If you only want a quick chat box, this is probably more app than you need.
Sentinel keeps its state on your machine.
That means SQLite for app data, encrypted stored credentials and config, local backup and export tools, and optional memory that stays off by default.
This is a desktop app first. A lot of the useful parts depend on running close to the local repo and local tools.
- Bun 1.4.2 or later
- Node.js 24 LTS, 24.14 or later (see
.nvmrc) - On Linux, build tools for
node-pty, which has no prebuilt Linux binary:build-essential,python3,make, andg++ - On macOS and Windows, build tools only if the native repair step asks for them:
- macOS: Xcode Command Line Tools
- Windows: Visual Studio Build Tools with Desktop development with C++
bun install
cp .env.example .env
bun run dev:desktopThe app runs at http://localhost:3232.
ENCRYPTION_KEY can be left empty in .env. Sentinel will generate one on first desktop launch.
Electron no longer downloads its binary during bun install. bun run dev:desktop and the desktop build commands fetch it on first use; run bun run electron:install to download it ahead of time.
Sentinel checks its native Node dependencies at startup. better-sqlite3 loads the N-API prebuild bundled for your OS and CPU and is never compiled locally; on Linux that prebuild needs glibc 2.34 and libstdc++ from GCC 11 or newer. node-pty uses its prebuilt binary on macOS and Windows; on Linux, bun install compiles it. If the node-pty binary does not load, the startup script rebuilds it locally and prints the platform package to install when build tools are missing.
On Linux, Sentinel disables Electron's Chromium process sandbox by default for compatibility with systems where user namespaces or the setuid sandbox are unavailable. Linux packages also launch with --no-sandbox from their desktop entries. Set SENTINEL_LINUX_SANDBOX=true when launching the executable directly to force the Chromium sandbox back on.
| Variable | Required | Description |
|---|---|---|
ENCRYPTION_KEY |
No | Generated on first launch if omitted |
SENTINEL_DB_PATH |
No | Custom path for the local SQLite database |
SENTINEL_STATE_PATH |
No | Custom path for app state |
SENTINEL_APP_URL |
No | Override the default app URL |
SENTINEL_LINUX_SANDBOX |
No | Set to true to force Electron's Chromium sandbox when launching the Linux executable directly |
SENTINEL_DISABLE_REMOTE_MANIFEST |
No | Turn off the hourly engine manifest refresh and use the bundled copy |
SENTINEL_DISABLE_ENGINE_UPDATE_CHECKS |
No | Turn off the hourly lookups for newer engine CLI releases |
bun run build:desktop:macFor a single architecture package:
bun run build:desktop:mac:arm64
bun run build:desktop:mac:x64For signed macOS builds, see docs/macos-signing.md.
bun run build:desktop:windowsbun run build:desktop:linuxFor an explicit architecture package:
bun run build:desktop:linux:arm64
bun run build:desktop:linux:x64Sentinel is desktop-first. A lot of the useful parts depend on being close to the local repo and local tools.
State stays on your machine unless you connect external providers or integrations.
Updates are currently distributed through GitHub Releases.
Apache-2.0