VibeAround
Keep your vibe coding agents around.
Start new thread

VibeAround v0.6.9: per-agent launch commands, IM session fixes, and preview polish

by•

VibeAround v0.6.9 is out.

This release is about making local coding agents easier to launch, resume, and reach from web/IM surfaces.

What changed:

- Added per-agent launch settings, so each agent can have custom terminal arguments and agent-protocol arguments inserted into the generated launch command

- This covers Codex sandbox / permission-mode / YOLO-style workflows without making the feature Codex-only

- Improved IM session behavior: IM can resume the latest session without replaying old message playback, with a setting to control auto-continuing the last IM session

- Tested preview and Markdown preview flows across direct launches, bridged profiles, web chat, and multiple agents

- Added a copy button for browser pairing commands

- Fixed Claude Code launches for token-based auth by restoring the expected auth-token environment variable shape

- Published signed and notarized macOS DMG, plus Windows installer/MSI/portable ZIP and Linux AppImage/deb

Release:

If you use VibeAround with Codex, Claude Code, Pi, Gemini, or bridged model profiles, this should make the launch path a lot more transparent and customizable.

46 views

Add a comment

Replies

Best

The per-agent launch args is the kind of fix you only think of after living with several agents at once. Reaching a local agent from a web or IM surface is the part I keep wanting and rarely see done cleanly. Is the IM bridge tied to one agent or can it route to whichever one is live?

 Thanks Andrii, that’s exactly the workflow I want VibeAround to make feel natural. The IM bridge is not meant to be tied to one fixed agent only. It talks to VibeAround’s session layer, so it can resume the latest IM session or reach the active session you launched/picked. In practice, you can run Codex, Claude Code, Gemini, Pi, etc. from the same control surface, then continue from IM. I’m still polishing the UX so it’s always obvious which agent/session you’re talking to.

 The 'which agent am I talking to' bit is the part I'd guard hardest. Once one surface spans Codex, Claude, and Gemini, the session identity has to be loud or people lose the thread fast.

@theuniverseson Thanks Andrii, totally agree. The "which agent am I talking to?" state has to be impossible to miss, not something users infer from history.

I'm treating agent/session identity as part of the UX contract: every surface should make the active agent, profile, workspace, and session visible, and every switch or pickup should confirm what changed before the next message goes out.

The routing layer can already reach different live or resumed sessions, but the product needs to make that state loud enough that users never feel they're guessing. I've started moving in that direction with the newer Runtime Status work, and the next step is bringing the same identity cues directly into Web Chat and IM flows. If a route is ambiguous, I'd rather VibeAround ask or confirm than silently send a message to the wrong agent.

 Treating agent identity as a UX contract is the right instinct. Confirming before you send on an ambiguous route is the bit most tools skip, and it's exactly where the silent wrong-agent message slips through. Making the state loud beats hoping people infer it from history.

Per-agent launch settings are a smart direction. Once people run different coding agents for different tasks, the workflow needs more than one generic launch command — each agent needs the right context, flags, and recovery path to stay useful.

 Thanks Alper, totally agree. A single generic launch command starts to break down once agents have different flags, auth modes, sandbox behavior, and resume semantics. The goal here is to keep those differences per-agent while still letting VibeAround generate the launch path consistently.