OpenMake Companion 0.2.1

The build targets macOS 14 or later on Apple Silicon and is unsigned (ad-hoc), so Gatekeeper quarantines it on first launch and reports it as damaged. It is not damaged; macOS is saying it does not recognise the signer.

Drag OpenMake Companion.app to /Applications first, then clear the quarantine attribute once. The app deliberately has no Dock icon — once it opens, look for the folder glyph in the menu bar.

xattr -dr com.apple.quarantine '/Applications/OpenMake Companion.app'

The Companion is an execution node, not a second OpenMake client. It keeps one job — being the machine an agent task can reach — and hands everything else back to the browser. That boundary is the point: a feature the web gains does not have to be built twice.

• Connect and disconnect work folders, and read the live state of each one
• Answer the execution confirmation dialog that a shell command cannot bypass
• Get a notification when a task ends, and click it to land on that task in the web
• No chat interface — “Open in web” hands the conversation back to the browser

Pick a folder from the menu bar. Only its name reaches the server, never the full path, and from then on an agent task can request work inside it through the bridge. Several roots can be connected at once — each gets an independent bridge connection under a derived device id, so scope, sandbox, and blanket approval stay separate per folder. One user is capped at three connected devices by default.

• Access is scoped by a fixed RPC allowlist and realpath checks, so symlinks cannot walk out of the folder
• Clearly dangerous commands are denied immediately
• Every remaining shell command requires user confirmation that cannot be bypassed
• sandbox-exec blocks writes outside the connected folder and reads from secret paths

The Companion authenticates with an API key carrying the bridge scope, issued from API keys in the web settings. The key is stored in the macOS Keychain and handed to the helper process through its environment rather than its command line, so it does not show up in a process list. The backend picker switches between the hosted service and a local instance on port 52416.

The updater reads the native channel of the server manifest, accepts only HTTPS or loopback origins, and verifies the SHA-256 of the download before it replaces the running application.

The Electron desktop app was frozen and then removed from the source tree once its bridge moved into that shared core. Nothing breaks for an existing install: the update manifest still carries its channel and the last build stays downloadable. Only new publishing has stopped, and local agent work belongs to the Companion from here.

The one thing the Companion does not replace is the in-app chat window, because that is the browser's job now. If you want that window, the last Electron build is still served.

Close