VibeAround v0.7.1-beta: Claude/Codex Desktop via 3rd-party APIs + Startkit onboarding
VibeAround v0.7.1-beta is now the latest release.
This beta focuses on the new Startkit flow and desktop-agent launch experience:
- Reworked Startkit checks with per-item progress and scoped cache keys
- Added system-vs-managed agent source detection
- Added direct desktop launch targets and desktop app detection
- Added Claude Desktop and Codex Desktop profile launch support with managed bridge/profile overlays
- Improved Launch UI for CLI and desktop agents
- Added a nine-grid terminal layout in the Web dashboard
- Fixed Gemini resume, attachment dedupe, quick-launch refresh, and terminal/workspace picker edges
- Refreshed the VibeAround logo across README, desktop top bar, tray/app icons, and Web dashboard
Downloads are available for macOS Apple Silicon, Windows x64, and Linux x64.
Release notes and packages: https://github.com/jazzenchen/VibeAround/releases/tag/v0.7.1-beta
Replies
Solid release. The new Startkit flow and bridge overlays make onboarding smoother, and the nine‑grid terminal layout shows you’re thinking about developer experience. Impressive that you’re investing in both CLI and desktop paths. How do you see VibeAround balancing power users with teams that prefer a simple desktop start?
VibeAround
@ievgen_chugunov Thanks Ievgen! I read “teams” as small engineering/product teams where not everyone wants to deal with API keys, bridges, or profile setup.
That’s exactly the balance I’m aiming for: power users can still go deep, but the default desktop path should be simple enough that a teammate can install VibeAround and get started without understanding all the plumbing.
@jazzenchen You framed the balance well, power users want the deep plumbing, but teammates need a frictionless desktop start. What struck me is that the nine‑grid terminal layout plus desktop launch targets suggest you’re designing for two very different usage modes: heavy agent orchestration vs. quick entry points. That duality is tricky because the more you simplify onboarding, the more you risk hiding the knobs advanced users rely on.
In my own builds, I’ve found it helps to decide whether the “default path” is just a demo experience or a real production workflow. If it’s the latter, you end up maintaining two overlapping UXs.