Four of the thirteen supported agents are forks reading the same Claude Code hook format

Four of the thirteen agents are Claude Code forks reading one hook format

The headline number is thirteen supported agents, and the compatibility table underneath is the interesting part. Four entries are described in exactly the same terms: Qoder, Qwen Code, Factory, and CodeBuddy, each labelled a Claude Code fork, each using the same hook format, and each with a configuration path that differs only in the directory name, ~/.qoder/settings.json, ~/.qwen/settings.json, ~/.factory/settings.json, and ~/.codebuddy/settings.json. So a quarter of the supported list is one integration applied four times, which is worth knowing before treating thirteen as thirteen separate engineering efforts. The remaining nine are distinct: Claude Code and its desktop app, Codex and its desktop app, OpenCode, Cursor, Gemini CLI, Kimi CLI, Grok Build, Pi, and Oh My Pi. The table also has fifteen rows rather than thirteen, because Claude Code and Codex are each split into a command line row and a desktop application row, and the two desktop rows are where the integration approach changes most.

Six integration mechanisms, and the approval round trip only where hooks exist

How the app talks to each agent is not uniform, and the permission feature depends entirely on which mechanism applies. Claude Code uses hook integration with JSONL session discovery and a status line bridge. Codex gets SessionStart, UserPromptSubmit, and Stop by default, with PreToolUse and PostToolUse described as parseable but not default, which is to say the approval path exists there but is not switched on. Kimi CLI has a permission flow that reuses the Claude payload, configured in a TOML table rather than JSON. Grok Build uses fire-and-forget events with a camelCase payload and is stated to have no permission round trip yet, so the app learns about its activity after the fact and cannot hold it. Gemini CLI is also fire-and-forget. OpenCode integrates as a JavaScript plugin with permission and question flows. Pi and Oh My Pi are TypeScript extensions covering the full lifecycle. The desktop apps take a third route entirely, with the Codex desktop app using an app server JSON-RPC connection for real time thread and turn lifecycle.

The Homebrew cask is open-island and the repository is open-vibe-island

Two install routes and one naming mismatch. The download route takes the latest signed and notarized DMG from the releases page. The package manager route is a cask, and the command is:

brew install --cask open-island

with the upgrade path given as `brew upgrade --cask open-island`. The cask is named open-island while the repository is open-vibe-island, and the releases are titled Open Island. So the product name, the cask name, and the repository name are three different strings for the same app, which is exactly the kind of thing that breaks a script written from the repository URL. The third route is to build from source, and it is three lines:

git clone https://github.com/Octane0411/open-vibe-island.git
cd open-vibe-island
open Package.swift   # Opens in Xcode — hit Run

Note what that recipe has and does not have. There is no dependency step, no install step, and no build command, because the project is a Swift package manifest and the build is a button in Xcode. The stated requirements are macOS 14 or newer, Swift 6.2, and Xcode.

An ios directory sits at the root and the document never mentions it

The repository root is .editorconfig, the GitHub configuration, AGENTS.md, CLAUDE.md, two contributing guides in English and Simplified Chinese, the licence, a privacy policy, Package.swift, two readmes, Sources, Tests, an appcast file, and five directories: Assets, config, design, docs, ios, plus scripts. The ios directory is the one that has no counterpart in the document. Everything described is a menu bar and notch application for the Mac, with a Sparkle based auto-updater and an Apple notarized DMG, and no iOS target, no iOS build step, and no iOS feature appears anywhere in the visible text. So either the iOS code is a planned target, an internal experiment, or a side project sharing the repository, and nothing in the documentation says which. The same is true of the design directory, which at least has an obvious purpose, while a platform directory with no release path is a different kind of loose end.

Claude Desktop runs the CLI somewhere process discovery cannot see it

The desktop application rows are where the document explains itself at length, and the Claude one is a genuine limitation rather than a feature. The reasoning is given: Claude Desktop runs Claude Code as a TTY-less subprocess that is invisible to process discovery, so liveness follows the running desktop app, the same way it does for Codex.app, and jump-back activates Claude rather than a terminal. Codex's desktop app does not have that problem and gets a better answer for it: an app server JSON-RPC connection for real time thread and turn lifecycle, plus a precise conversation jump through a `codex://threads/<id>` deep link. The usage panel has a related asymmetry, being account-wide but seeded by the command line status line, so the numbers you see come from the CLI even when the session you are looking at is in the desktop app. Both details are the kind of thing you only discover by running the app, and both are written down here.

Two releases on one day, and the last three read as fix notes

The release titles are changelogs rather than version strings, and reading them in order says something about where the project is. v1.1.9 is Usage Windows, Conductor and Stability Fixes. v1.2.0 is Grok Build, Pi and Oh My Pi. v1.2.1 is Click Handling, Panel Morph and Jump-back Fixes. So one of the three added integrations and two of the three are fixes, and the two fix releases touch the same surface: the panel and the jump-back, which is the part a user notices immediately when it misbehaves. Two of them also landed on the same day, 2026-09-03, five hours apart, and the newest one is 2026-09-15, an hour after the last commit to the tree. The cadence is roughly a fortnight at the moment, which is fast for a menu bar app but reasonable for one whose whole value is not interrupting a session with a misbehaving overlay.

The local-first claim is specific and there is a privacy policy and an appcast to match

The claims about data are short and checkable. No server, no telemetry, no account, and everything runs on your Mac. Session discovery works from local transcripts and is persisted across launches, so the app holds a record of your agent conversations on disk. The appcast file at the root is the feed behind the Sparkle based automatic updates, and the release route is signed and notarized DMG packaging with Apple notarization, so the update path is a signed channel rather than a plain download. A privacy policy file sits beside the licence, and the project describes itself as an open source alternative to a named closed source product, licensed GPL v3 with the invitation to fork, modify, and ship your own version. Interface languages are English and Simplified Chinese, and the overlay adapts: the notch area on notch Macs, a top-centre bar on the others.

Editorial conclusion

Open Island fits someone running more than one coding agent at a time who has stopped noticing which terminal window a prompt is waiting in, and who would rather not pay for a commercial equivalent or hand session transcripts to a server. Check four things. Which of your agents you actually need gated, because the approval flow is not uniform and two of the integrations only report events after they happen rather than being able to hold one. What the hooks write, since each agent stores its configuration in a different dotfile and four of them are forks of Claude Code reading the same format. Which install route you script, because the Homebrew cask is named differently from the repository. And whether an unsigned build is acceptable to you, since the download route is signed and notarized while the source route hands you an Xcode project to run yourself.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. Octane0411/open-vibe-island on GitHub
4. README
5. Releases