The Safeguard desktop application is generally available at 1.0 on macOS (Intel and Apple Silicon), Windows (x64 and ARM64), and Linux (x64 deb, rpm, and AppImage). It is a real desktop application — not a web shell — built with a native shell per platform and a shared Rust core for the scan, classify, reach, and remediate loops.
Why a desktop app in the first place: we ship a web app at app.safeguard.sh that covers most workflows, but there are three things a desktop app does better. It can run workflows fully local without sending code to a backend, it can stay useful when the network is unreliable, and it can hold developer credentials (git, package registries, cloud) in the OS keychain rather than asking for them again in a browser session. Those three capabilities are what 1.0 delivers.
What does the desktop app actually do?
Answer first: it runs the full Safeguard workflow engine locally, with optional backend sync.
The app has four panes. The first is a repo list — the repositories and images on your machine that Safeguard is watching. The second is a findings feed with the same shape as the web app: Eagle 3.0 classifications, reachability badges, severity, and the workflow that produced the finding. The third is a workflow runner — you can kick off any of the 50+ library workflows or your own custom ones against a local repo, watch the run live, and approve or reject Griffin's proposed steps. The fourth is a compliance view — the Lino 2.0 control-to-evidence matrix scoped to your workspace.
The engine that runs under these panes is the same Rust core that powers the Local Runner. That means workflows authored in the web app, the IDE extensions, or the MCP Server run identically on the desktop. The desktop is the most convenient place to run long or network-heavy workflows because it does not time out the way a browser session does and because the filesystem and shell access are direct rather than tunneled.
Two specific capabilities that matter because they were awkward in the web app. First, reachability analysis on a large monorepo can take several minutes the first time; the desktop can run it in the background and cache it locally across sessions. Second, Griffin remediations that need to run your test suite do so against your local environment rather than a sandbox, which is faster and more faithful to whatever local dev setup you already have.
How is it different from the web app?
Three things the desktop does that the web cannot: fully local mode, OS-keychain credentials, and direct filesystem workflows.
Fully local mode is an option on the repo level. Turn it on and the desktop runs scan, classify, reach, and remediate against that repo without sending contents to the backend. The models run locally — Eagle 3.0 has a distilled local variant, Lino 2.0 has a local rules-only variant, Griffin's local variants are 2.5 and the 3.1-preview — and the findings stay on your machine. You can sync findings to the backend on demand if you want compliance evidence to flow into Lino, but the default in local mode is that nothing leaves your laptop.
The local models are smaller and slightly less accurate than the cloud-hosted ones. Concretely: Eagle local is about 3 points lower on F1 for malware classification, Lino local covers the built-in frameworks but not custom controls, and local Griffin is fine for single-repo remediations but does not see cross-repo context. For most developer-laptop use cases, these trade-offs are acceptable, which is why this mode exists.
OS-keychain integration uses macOS Keychain, Windows Credential Manager, and libsecret on Linux. The app does not store secrets in its own config. This matters because the alternative — asking users to paste a PAT into a config file — is a pattern that does not age well.
Direct filesystem workflows make it practical to run Safeguard against repos that are not yet pushed to a remote, against images that are only in the local Docker daemon, and against dependency manifests that exist only as work-in-progress. The web app cannot see any of these. The desktop can.
How does it interact with the web app and the IDE extensions?
Answer first: they share a workspace model, and you can flip between them without re-authing.
A workspace lives in the backend. The desktop, the web app, the IDE extensions, the MCP Server, and the Local Runner all connect to the same workspaces. Findings created in one surface are visible in the others. Workflow runs are shared. Approvals flow across surfaces — a remediation kicked off from the desktop can be approved from the web app by a second reviewer, and the desktop will reflect that approval in real time.
The IDE extensions for VS Code, Cursor, and the JetBrains family are thin clients that talk to the desktop when the desktop is running, and to the backend directly when it is not. This is the single biggest quality-of-life change in 1.0 — when the desktop is running, the IDE extensions use the desktop's local model cache and reachability graph, which makes inline annotations appear in single-digit-millisecond response times rather than round-tripping through the backend.
# ~/.config/safeguard/desktop.toml
[default]
workspace = "acme-prod"
region = "us"
[local_mode]
enabled_for = ["acme-prod/research", "acme-prod/experimental"]
local_models = ["eagle@3.0-local", "lino@2.0-local", "griffin@3.1-preview-local"]
[integrations]
vscode = true
cursor = true
jetbrains = true
What should I know about security and enterprise deployment?
Answer first: it is code-signed, supports managed deployment channels, and respects org-level policy.
The macOS build is Developer ID signed and notarized. The Windows build is Authenticode-signed with an EV certificate. The Linux builds are signed with a GPG key whose fingerprint we publish at a stable URL; the .deb and .rpm repos are signed as well. Updates are signed end-to-end and the updater verifies the signature before switching the binary.
For managed deployments, there is an enterprise channel that lags the public channel by two weeks and a lts channel that lags by a release. We publish MSI for Windows, PKG for macOS, and repository configuration for Linux package managers. MDM profiles for Jamf and Intune are available — they pre-fill the workspace and region and lock the auth flow to your IdP.
Organization policy, configured in the web app, propagates to the desktop on first login. A workspace can forbid local mode entirely (the most common setting for regulated workloads), pin the Griffin version, restrict which workflows can run from the desktop, and require approval for any action that writes to a repo. The desktop honors policy locally even when offline — it refuses to run a disallowed workflow rather than waiting until it can phone home.
The app's data directory on disk is encrypted at rest (FileVault/BitLocker/LUKS passthrough on each platform) and the local model caches are scoped per workspace. Uninstalling the app removes the caches; the credentials in the OS keychain persist until revoked from the web app or deleted by the user.
How Safeguard.sh Helps
The desktop application is where the full platform becomes usable offline and fast. It runs the same workflow engine as the web app and the MCP Server, with 50+ templates available out of the box, and it hosts the Local Runner as a first-class component. The IDE extensions for VS Code, Cursor, and the JetBrains family become much quicker when the desktop is running because they share the local model cache and reachability data. For regulated workloads, the same policy, Lino 2.0 evidence pipeline, and FedRAMP HIGH, IL7, and SOC 2 Type II coverage that apply to the web app in the Gov region apply to the desktop — there is no separate compliance story. If you are a developer, starting with the desktop and the IDE extension gives you most of the platform's day-to-day value with the shortest setup path.