Releases

Download VibeCody release packages below. All binaries are built via GitHub Actions with SHA-256 checksums.

Quick install (Linux/macOS):

curl -fsSL https://raw.githubusercontent.com/TuringWorks/vibecody/main/install.sh | sh

v0.5.8 — Latest

Released: August 10, 2026 · Release notes · Changelog

The largest release so far — 410 commits since v0.5.7. Voice input on every client, SkillForge, the kodegraph code-graph substrate, goal-driven loops, a provider-agnostic embedding layer, and the VibeApp → VibeAIChat rename that brings VibeDesk in as a third desktop shell.

Highlights

• Voice input everywhere — one daemon route (POST /voice/transcribe) and one shared React hook behind mic buttons in all three desktop shells, VibeMobile, and the VS Code / JetBrains / Neovim plugins. Groq Whisper with a local whisper.cpp fallback, so it works offline.
• Choose your embedding model — semantic search and @codebase: now run on Ollama, OpenAI (or any OpenAI-compatible endpoint), Voyage, Cohere, Gemini, or an in-process local model. Indexes are kept per-model, so switching is instant and switching back never re-embeds. See Embedding Models.
• SkillForge — analyse and train agent-skill documents (SkillLens + SkillOpt) from a VibeCoder panel, the REPL, the TUI, and ten daemon routes.
• Code graph (kodegraph) — a tree-sitter → SQLite knowledge graph built in the background on daemon start, feeding a compact repo summary into the agent prompt in place of a flat directory tree.
• Goal-driven loops — /loop goal <id> runs until a goal’s success_criteria verifiably hold, judged by a separate validator turn rather than the worker’s own opinion.
• VibeDesk ships for the first time, alongside VibeCoder and VibeAIChat.

Notable fixes

• macOS artifacts can now be Developer ID signed end to end, vibecli included — see Code signing to check what you downloaded.
• The code index no longer writes API keys to disk; pre-existing indexes are migrated and the credential dropped.
• Switching embedding model used to return silently wrong results; indexes and memory rows now carry the model that produced them.
• VibeAIChat now autostarts the daemon like the other shells, and all three recover from a rotated bearer token instead of looping on 401.
• VibeCoder chat renders markdown — tables, headings, emphasis — instead of raw text.
• Theme tokens: two names referenced across 33 sites were never defined, so those borders and button fills never rendered.

VibeCLI — Terminal AI Assistant

VibeCoder — Desktop Code Editor

VibeAIChat — Desktop AI Assistant

VibeDesk — Desktop Task Shell

VibeMobile — Flutter Companion

VibeWatch — Apple Watch & Wear OS

SHA256SUMS.txt

Code signing

v0.5.8 adds Developer ID signing to the whole macOS surface — including the vibecli binary, which previously shipped with no signature at all.

Whether a specific download is signed depends on the build that produced it: the release workflow signs only when the APPLE_CERT_P12_BASE64 secret is configured, and falls back to ad-hoc (apps) or unsigned (CLI) with a workflow notice otherwise. Rather than take this page’s word for it, check the artifact you actually have:

codesign -dv --verbose=4 /Applications/VibeCoder.app
# expect: Authority=Developer ID Application: Ravindra Boddipalli (N7HV58M58W)
# a line reading "Signature=adhoc" means the artifact is NOT the signed release

codesign --verify --deep --strict --verbose=2 /Applications/VibeCoder.app
# expect: "valid on disk" and "satisfies its Designated Requirement"

The standalone vibecli binary in the macOS tarballs is signed with the same identity:

codesign -dv --verbose=4 ./vibecli

Notarization status. Signing and notarization are separate steps. A signed but un-notarized app still shows the “unidentified developer” prompt on first launch — use right-click → Open, or strip the quarantine attribute as described below. Check whether a given build was notarized:

xcrun stapler validate /Applications/VibeCoder.app   # "worked!" = notarized
spctl -a -vvv -t install /Applications/VibeCoder.app # "source=Notarized Developer ID"

Maintainers: see macOS code signing setup for the full credential list and the local build recipe.

v0.5.7

Released: May 29, 2026 · Release notes · Changelog

Previous release. VibeDesk is not listed: it did not exist yet in v0.5.7.

VibeCLI — Terminal AI Assistant

VibeCoder — Desktop Code Editor

Shipped as VibeUI — the rename to VibeCoder landed after this release, so the filenames still say VibeUI.

VibeAIChat — Desktop AI Assistant

Shipped as Vibe.App — renamed to VibeAIChat after this release.

VibeMobile — Flutter Companion

VibeWatch — Apple Watch & Wear OS

SHA256SUMS.txt

Installing on macOS

Applies to every release; not specific to the version above.

macOS install: the app is killed on first launch

Symptom. The app bounces once in the Dock and quits, or Finder says “«App» is damaged and can’t be opened. You should move it to the Trash.”

It is not damaged, and re-downloading will not help. Every macOS artifact built by CI is ad-hoc signed with the hardened runtime enabled, because the release workflow has no Developer ID certificate (APPLE_CERT_P12_BASE64 is unset — see macOS code signing setup). macOS refuses to run that combination while the download-quarantine flag is set, and it does so by killing the process — verified: the binary exits with signal 9 (exit=137) while quarantined, and starts normally the moment the flag is removed.

Fix — remove the quarantine flag:

xattr -dr com.apple.quarantine /Applications/VibeCoder.app
xattr -dr com.apple.quarantine /Applications/VibeAIChat.app
xattr -dr com.apple.quarantine /Applications/VibeDesk.app

Run it once per app, after moving it to /Applications. That is the whole fix; the app launches immediately afterwards.

Why not “right-click → Open”? That is the standard advice for an unidentified developer prompt, and it is what this page used to recommend first. It does not reliably clear this state: the hardened runtime turns the Gatekeeper rejection into a kill rather than a prompt, so there is often no “Open anyway” dialog to click. Use the xattr command.

spctl will still report rejected afterwards. That is expected — it means “not Developer ID signed”, and it stops mattering once the quarantine flag is gone, because Gatekeeper only assesses quarantined files.

The real fix is on the maintainer side: configure the signing secrets below so releases ship Developer ID signed and notarized, at which point none of this is necessary for anyone.

macOS code signing setup (for maintainers)

One-shot setup: run scripts/setup-apple-signing.sh on a Mac that already has the Developer ID certificate installed. It picks the identity, derives the Team ID from it, verifies the exported .p12 actually contains a private key, checks the notarization credentials against Apple before uploading anything, and then sets all six secrets with gh. Nothing leaves the machine except the encrypted secrets themselves.

Coverage. These six secrets sign and notarize VibeCoder, VibeAIChat, VibeDesk and vibecli. A bare binary cannot carry a stapled ticket (stapling only works for .app/.dmg/.pkg), so vibecli’s ticket is fetched from Apple on first run — but it is notarized, which is what Gatekeeper checks.

iOS and watchOS are a separate, optional phase — and they need a different certificate. Developer ID signs macOS apps distributed outside the App Store and cannot sign an iOS or watchOS bundle at all; those need Apple Distribution. The script uploads each to its own secret so every job imports the identity it can actually use:

On top of the certificate, each mobile target needs a distribution provisioning profile for its App ID:

Each is gated independently — missing secrets mean that platform ships unsigned (and still sideloadable), never a failed release:

Android ships unsigned by design, for sideloading.

Each desktop job now verifies its own .app after building and fails the release if it is still ad-hoc — the check vibecli always had and the app bundles never did, which is why ad-hoc builds shipped unnoticed.

APPLE_KEYCHAIN_PASSWORD is not required — the workflow generates a throwaway password per job for a keychain that never outlives it.

The manual equivalent is below.

If Keychain Access greys out the .p12 option, you do not need it — the script exports via the security CLI, which only asks for your keychain password. The greying is usually one of:

The script exports every identity, keeps only the one being used (matching the certificate to its private key by public modulus, since order is not guaranteed), and rebuilds a .p12 with a single private key. Other certificates travel as chain material only — public data, no keys.

To ship fully Apple-notarized builds (no first-launch warning at all), add the following repository secrets:

As of v0.5.8 none of these secrets are configured on the repository, so a tag push produces ad-hoc app bundles and an unsigned vibecli. Confirm before cutting a release you intend to be signed:

gh api repos/TuringWorks/vibecody/actions/secrets --jq '.secrets[].name'

Upload them with gh secret set NAME (the .p12 export and its password come from Keychain Access → export the Developer ID Application identity).

The build-cli, build-vibecoder, build-vibeaichat and build-vibedesk jobs auto-detect these secrets — when APPLE_CERT_P12_BASE64 is unset, the build emits a workflow ::notice:: and falls back to ad-hoc signing. The watchOS-signed track uses a parallel set of secrets (APPLE_PROVISIONING_PROFILE_BASE64 + App Store Connect API key) — see .github/workflows/release.yml build-watchos-signed for that path.

VibeDesk ships from v0.5.8. It has a build-vibedesk release job (same five-platform matrix and dual-mode signing as the other two shells) and a vibedesk-checks CI job; it was absent from v0.5.7 and earlier. Two things to know about it:

• It is not in the release job’s critical if: gate yet. The job has never run on Linux or Windows, so a failure there must not block the whole release. Promote it by adding needs.build-vibedesk.result == 'success' once it has shipped green.

• Its src-tauri embeds the whole vibecli crate for direct ProfileStore access — exactly as VibeCoder does — so its build cost tracks VibeCoder’s. On macOS that includes the Metal mistral.rs backend, which vibecli pulls unconditionally through a [target.'cfg(target_os = "macos")'] block regardless of feature flags.

  As of v0.5.8 all three shells carry that cost: VibeAIChat took the vibecli dependency too, so it can autostart the daemon through the shared daemon_bootstrap instead of having no way to start one. It previously embedded no Rust of its own and built in a fraction of the time.

Signing and notarizing locally

CI is not required — a local make build-ui will sign and notarize once the same variables are in your environment. Two prerequisites:

1. The Developer ID Application certificate must be in your login keychain. The APPLE_CERT_P12_BASE64 secret is a CI-only mechanism for importing it into a throwaway runner keychain; locally you install the cert once from your Apple Developer account. Confirm it is there:

   security find-identity -v -p codesigning | grep "Developer ID Application"
   

2. APPLE_PASSWORD must be an app-specific password, generated at appleid.apple.com → Sign-In and Security → App-Specific Passwords. Your normal Apple ID password is rejected.

Then export the four variables and build:

export APPLE_SIGNING_IDENTITY="Developer ID Application: Acme Inc (TEAMID)"
export APPLE_TEAM_ID="XXXXXXXXXX"
export APPLE_ID="you@example.com"
export APPLE_PASSWORD="xxxx-xxxx-xxxx-xxxx"   # app-specific, not your Apple ID password

make build-ui

APPLE_SIGNING_IDENTITY overrides the "signingIdentity": "-" in tauri.conf.json, so the committed config stays ad-hoc and no one needs a certificate for an ordinary development build. Leave the variable unset and you get today’s behaviour.

Notarization is a round trip to Apple’s servers — budget 2–15 minutes per build on top of compile time. If you only want a runnable app, skip it; the warning in the build log (skipping app notarization…) is informational, not an error.

Verify the result:

codesign -dv --verbose=4 target/release/bundle/macos/VibeCoder.app   # expect your Developer ID, not "adhoc"
xcrun stapler validate target/release/bundle/macos/VibeCoder.app     # expect "The validate action worked!"
spctl -a -vvv -t install target/release/bundle/macos/VibeCoder.app   # expect "accepted / source=Notarized Developer ID"

Building all three shells locally keeps only the last DMG

The three Tauri shells share the workspace target dir, and Tauri clears target/release/bundle/dmg/ before writing its own image. Build them in sequence and you get three DMGs built, three DMGs signed — and one DMG on disk. The .app bundles live in a sibling directory and all three survive, which is what makes the loss easy to miss: the build log reports every DMG created and signed, and checking the apps shows all three present.

make build-apps stages each shell’s bundles into dist/ before the next build clears them. If you drive tauri build by hand, copy the DMG out between shells.

CI is unaffected: each shell builds on its own runner with its own target dir.

Related: tauri build --bundles dmg deletes the .app after bundling it, so re-running it for one shell removes that shell’s app bundle. The app is inside the DMG; mount it if you need the bundle back.

DMG bundling fails with error running bundle_dmg.sh

bundle_dmg.sh drives Finder over AppleScript to position icons and set the window background. When that osascript call fails the script exits 64, and Tauri reports only failed to run …/bundle_dmg.sh — the underlying reason is not surfaced.

The reliable fix is to skip the AppleScript, which Tauri does when it is told it is running in CI:

CI=true make build-ui        # note: CI=true, not CI=1

Tauri binds the CI environment variable to its own --ci flag, which accepts only true or false — CI=1 fails immediately with error: invalid value '1' for '--ci'. With CI=true the bundler passes --skip-jenkins, the osascript call never happens, and the DMG builds. You lose only the cosmetics: custom window size, icon positions and background image. Drag-to-Applications still works, because the Applications symlink is created before the AppleScript runs.

This was verified on a machine where the styled path failed twice and CI=true succeeded immediately.

Other things worth checking:

• A leaked scratch volume. A failed run leaves its disk image mounted, which breaks every retry with a confusing second error. Always clean up before rebuilding:

  ls -d /Volumes/dmg.*                     # any match is a leftover
  hdiutil detach /Volumes/dmg.XXXXXX
  rm -f target/release/bundle/macos/rw.*.dmg
  

• Automation permission, if you want the styled DMG: System Settings → Privacy & Security → Automation → your terminal app → enable Finder. A previous “Don’t Allow” is remembered and must be re-enabled here. Note this is per-app, and the process that actually sends the Apple event is node/osascript under your shell — a grant for one terminal does not cover a build launched from another.
• The -1728 “Can’t get disk” race. bundle_dmg.sh guards it with a fixed 2-second sleep after mounting, which is not always enough on a machine that has just finished a heavy LTO link. Running the same script standalone on an idle machine can succeed where it failed under the build — so an intermittent failure here does not mean your permissions changed.
• No GUI session at all (SSH, a headless runner): there is no Finder to talk to, so CI=true is the only option.

Verify Downloads

# Download the checksums file
curl -LO https://github.com/TuringWorks/vibecody/releases/download/v0.5.8/SHA256SUMS.txt

# Verify
sha256sum -c SHA256SUMS.txt

Release History

For older releases (v0.5.6 and earlier), see github.com/TuringWorks/vibecody/releases.