Scarf: a native SwiftUI front end for the Hermes AI agent
Native macOS and iOS App for the Hermes AI agent — multi-window, multi-server (local + remote over SSH). Chat, dashboard, sessions, memory, cron, MCP, and more.
At a glance
- What is it?
- Scarf is a macOS and iOS client for the Hermes agent that reads Hermes state read-only and routes every mutation through the hermes CLI. It is worth adopting if you already run Hermes across one or more SSH-accessible hosts and want a GUI over its sessions, memory, cron and config.
- Who is it for?
- Adopt Scarf if you already run Hermes on a machine you can reach over SSH and you want dashboards, memory editing and cron management without hand-editing YAML. Skip it if you are not a Hermes user, if your hosts are not SSH-reachable, or if you need a Linux client, since the README lists only macOS 14.6+ and iOS 18+.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Swift, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap Scarf fills for Hermes operators
Hermes is described in the README as a terminal-and-messaging agent, and the project's own framing of the problem is blunt: it is "powerful, but invisible." Everything the agent does, including sessions, messages, tool calls, token counts and spend, lives in state that you inspect through a terminal or not at all. Scarf is a native macOS and iOS application that puts a window on that state. The audience is narrow and specific: people who already run Hermes, often on more than one host, and who want to see cost breakdowns, search message history, edit memory and skills, and manage cron jobs and MCP servers without reading YAML by hand. If you do not run Hermes, nothing here applies to you. The README's feature list is organised around visibility and control rather than around new agent capabilities, which is the honest way to read the project: Scarf does not make Hermes smarter, it makes Hermes observable and configurable.
Read-only state, CLI-mediated writes, and plain SSH as the transport
The architecture has three load-bearing choices. First, Hermes state is opened read-only, and management actions go through the hermes CLI, which the README says means "Scarf can't corrupt your agent's data." That is a real constraint as much as a safety property: anything the CLI cannot express is not something Scarf can do. Second, there is no companion service. Scarf connects to a local ~/.hermes/ directory or to remote hosts over plain SSH, reusing your existing ~/.ssh/config, agent and ProxyJump configuration. The README states there is "nothing between your device and your Hermes host," so there is no daemon to install on the server side and no relay to trust. Third, the UI is version-adaptive. Scarf detects each host's Hermes version and capability-gates its interface, with the README claiming support from Hermes v0.6 through v0.20; surfaces that only exist on newer Hermes releases simply hide on older hosts. The iOS companion, ScarfGo, uses a pure-Swift SSH implementation (Citadel) and generates an Ed25519 key on-device that lives in the iOS Keychain. That key is pasted into the host's ~/.ssh/authorized_keys by hand, which is the entire trust setup.
Building and connecting: what the repository actually documents
The README does not give a build-from-source command sequence in the material available here, so treat the following as the documented path rather than a verified one. The published route is the GitHub Releases page for the Mac download and the public TestFlight link for the iPhone build. The stated platform floor is macOS 14.6+ and iOS 18+, with the codebase on Swift 6 and the app targeting Hermes v0.20. For ScarfGo, the README describes a connection flow that it says takes about a minute: add a server using the same details you would pass to ssh user@host, tap Generate Key, paste the resulting public key into the host's ~/.ssh/authorized_keys, then tap Test connection. The Mac app has no equivalent key-generation step because it uses your existing SSH configuration. If you intend to build from source rather than use the release, the README and the wiki are the places to check for a toolchain section, because the repository description alone does not establish one. The one config key named in the release notes is Auto-accept edits, set per project in that project's Chat Settings.
The 3.1.0 project model and its safety machinery
Release 3.1.0 reorganises the sidebar around projects, which sit at the top in their own panel with folders, filtering, a context menu and a New Project button; the remaining sections collapse and expand, and Scarf remembers the arrangement. The more interesting change is Auto-accept edits. Turning it on for a project means chats bound to that project apply edits without prompting, though the release notes state that sensitive paths still ask and that this is enforced by Hermes rather than by Scarf. The setting is described as cryptographically bound to your machine, so an agent cannot grant itself the bypass. Approval dialogs also gained an "Allow edits for this session" button. Alongside that, the notes describe atomic writes on every transport including iOS SFTP, quarantine-and-refuse instead of overwrite when damage is detected, rolling backups, a cross-process write lock, a Project Doctor that reconciles and repairs, and trust re-verified at time of use through uninstall containment, per-project keychain binding and signed mini-app grants. Mini-apps gained an open_url permission that is https-only, confirmed per host by name, and never triggered without a click. This is a lot of machinery for a client application, and it tells you where the project believes the risk lives.
Where Scarf is the wrong tool
The read-only-plus-CLI design is the main limitation. If your workflow needs to write Hermes state directly, or if you depend on a Hermes feature that has no CLI surface, Scarf cannot reach it, and the README's safety claim is exactly the reason. The version-adaptive UI cuts both ways: on older hosts, newer-only surfaces hide rather than degrade, so a user on an old Hermes release may find whole sections simply absent with no explanation beyond the capability gate. ScarfGo requires you to edit ~/.ssh/authorized_keys on each host by hand, which is fine for one machine and tedious for several. The macOS app collects anonymous usage statistics by default, described as event names plus fixed-vocabulary properties with no content, paths, hostnames or persistent identifier; it is opt-out via Settings, then Advanced, then Usage Analytics. That default will not suit every operator, and the iOS app collects nothing, which is an asymmetry worth knowing before you standardise on one platform. Finally, the platform floor is high: macOS 14.6 and iOS 18 exclude older machines, and there is no Linux or Windows client in the README.
How Scarf differs from a terminal multiplexer or a web dashboard
The obvious alternative for a Hermes user is to stay in the terminal, using tmux or plain SSH sessions, and read Hermes output where it is produced. That approach has no install step, no platform floor and no analytics, and it will always expose every CLI capability the moment Hermes ships it. What it does not give you is a persistent, cross-host view: cost breakdowns across projects, full-text search over message history, or a single place to edit memory and cron entries. A web dashboard is the other shape of alternative, and the README's no-middleman claim is aimed squarely at it. A browser-based tool typically needs a server component reachable from your device, which means a listening service and its own authentication story. Scarf instead reuses SSH, which you already run and already trust, and puts the UI on the device rather than on the host. The trade is that you get a native client only on Apple platforms, and you inherit SSH's own failure modes: key rotation, agent forwarding quirks, and ProxyJump chains that break silently.
Maintenance, licence and upgrade surface
Scarf is MIT licensed, which permits commercial and private use and modification, subject to the usual requirement to preserve the copyright and permission notice; that is a summary of the licence identifier, not legal advice, and you should read the LICENSE file in the repository if the terms matter to your organisation. The release cadence visible in the material is fast: v3.0.0 on 2026-09-02, v3.0.1 the next day, and v3.1.0 on 2026-09-04, with the last push to the repository on 2026-09-10. A three-release week suggests active development, and it also means the upgrade surface is real: the 3.1.0 notes describe a sidebar reorganisation and a new project-level setting, both of which change how the app is used rather than merely how it looks. Because Scarf tracks Hermes versions from v0.6 to v0.20 and capability-gates its UI, a Hermes upgrade on any of your hosts can change what Scarf shows you without Scarf itself being updated. The maintenance cost therefore sits in two places at once: keeping the app current, and keeping each host's Hermes version inside the range the app understands.
Editorial conclusion
Adopt Scarf if you already run Hermes on a machine you can reach over SSH and you want dashboards, memory editing and cron management without hand-editing YAML. Skip it if you are not a Hermes user, if your hosts are not SSH-reachable, or if you need a Linux client, since the README lists only macOS 14.6+ and iOS 18+. Before committing, verify that your Hermes version falls inside the documented v0.6 to v0.20 range, confirm the read-only state access and CLI-mediated writes behave as described against your own host, and check the Settings, Advanced, Usage Analytics toggle if anonymous event statistics are unwelcome.
Community notes