Open Vibe — Profile

A profile of Open Vibe as it lives in this study (studies/conversational-ui-and-native-shells/open-vibe/). LICENSE:1-3 confirms MIT, “Copyright (c) 2026 Thomas Ricouard / Copyright (c) 2026 citizenl”. Read alongside Profile__Routa.md (genuine per-session ACP process spawn, provider chosen per call) and Profile__Dive.md (one shared Python subprocess for the whole app) — Open Vibe sits between them: it genuinely spawns one real OS child process per workspace, with real per-workspace argv/env/cwd scoping, but the thing being spawned is always the same single binary (codex) — there is no adapter registry, no provider parameter, no swappable backend. It is a process-per-workspace supervisor around exactly one CLI, not a process-level adapter swap.

TL;DR

The repo’s own README says it plainly at README.md:35: “Start one codex app-server per workspace; list/resume/archive threads.” That is not marketing rounding — it is exactly what the code does. spawn_workspace_session (src-tauri/src/backend/app_server.rs:290-464) builds a tokio::process::Command, sets command.current_dir(&entry.path) (line 307), appends the literal argument command.arg("app-server") (line 308), sets CODEX_HOME from a per-workspace resolver if present (lines 309-311), and pipes stdin/stdout/stderr (lines 312-314) before command.spawn() (line 316). The resulting WorkspaceSession (app_server.rs:60-68) holds the live Child, its ChildStdin, and a pending: HashMap<u64, oneshot::Sender<Value>> for in-flight JSON-RPC-shaped requests keyed by an auto-incrementing next_id — a real line-delimited JSON-RPC-over-stdio protocol, confirmed by send_request/send_notification/send_response (app_server.rs:81-106) and the "initialize"/"initialized" handshake at lines 428-452.

Workspace scoping is real, not a config-row convenience: connect_workspace_inner (src-tauri/src/workspaces/commands.rs:1471-1520) looks up the WorkspaceEntry by id, resolves that workspace’s own codex_bin, codex_args (resolve_workspace_codex_args, commands.rs, worktree-inherits-from-parent then falls back to global app settings), and codex_home (resolve_workspace_codex_home, codex_home.rs:6-35, same inheritance chain plus a legacy .codexmonitor directory fallback), then spawns a session and inserts it into state.sessions: Mutex<HashMap<String, Arc<WorkspaceSession>>> (state.rs:15) keyed by workspace id. If a session already exists for that id and force_respawn isn’t set, connect_workspace_inner short-circuits and returns the existing one (commands.rs:1477-1481); if a stale session is being replaced, the old child process is explicitly killed (commands.rs:1515-1518). A dedicated GLOBAL_WORKSPACE_ID = "__global__" session exists for cross-workspace operations like listing all threads (codex.rs:31, 154-201, 415-449).

Verdict on the research summary’s claim: the “one codex app-server process per workspace over JSON-RPC/stdio” claim is fully confirmed and independently verified in app_server.rs and workspaces/commands.rs — this part is real, not shallow. But calling this a “genuine process-level adapter swap” (in the sense Routa’s AcpManager earns that label) overstates it: there is only one adapter. build_codex_command_with_bin (app_server.rs:173-196) always resolves to a binary literally named codex unless the user points codex_bin at a differently-named executable on disk — there is no provider parameter, no registry of alternative coding-agent CLIs (no Claude Code SDK, OpenCode, or Gemini CLI adapter anywhere in src-tauri/src/), and no protocol-normalization layer comparable to Routa’s ACP. What is swappable per-workspace is argv (codex_args), environment (CODEX_HOME), and cwd (entry.path) for the same binary — configuration-of-invocation, not adapter identity.

The workspace-to-process mapping — confirmed, with worktree inheritance

• One HashMap entry, one live child, keyed by workspace id. AppState.sessions (state.rs:15) is Mutex<HashMap<String, Arc<crate::codex::WorkspaceSession>>> — structurally identical in shape to what a “per-workspace process registry” should look like, and every read site (workspaces/commands.rs:125,135-136,271,332,468,584,708,733,776,916-955,1254-1449) treats contains_key/get/remove on this map as the connectivity source of truth for a given workspace id.
• Worktrees are a distinct WorkspaceKind that inherit config from their parent, not siblings that get their own default. WorkspaceKind::{Main, Worktree, Nanobot} (types.rs:223-227); resolve_workspace_codex_home (codex_home.rs:6-35) checks the worktree’s own override first, then falls back to parent_entry.settings.codex_home, then a legacy parent.path/.codexmonitor directory, then the global CODEX_HOME/~/.codex default — proven by three passing unit tests at codex_home.rs:222-249 (worktree_inherits_parent_codex_home_override, worktree_relative_override_uses_parent_path). resolve_workspace_codex_args (workspaces/commands.rs, mirrored logic) does the same for CLI args.
• A Nanobot workspace kind exists as a third case (types.rs:226,240-242, is_nanobot()) — evidence the workspace concept is reused for the DingTalk/QQ bot bridge, not solely for git-backed coding workspaces; this is a routing distinction inside the same sessions map, not a different process-spawn mechanism.
• A remote-backend escape hatch exists that is explicitly not process-per-workspace. remote_backend.rs:53-63 (RemoteBackend/RemoteBackendInner) opens one TcpStream to 127.0.0.1:4732 (DEFAULT_REMOTE_HOST, line 14) and multiplexes all calls (RemoteBackend::call, lines 65-80) through one connection with its own pending map — every workspace command checks remote_backend::is_remote_mode(&state) first (e.g. codex.rs:158,337,365,393,419) and if remote mode is active, routes through this one shared TCP connection instead of spawning anything locally. This is the repo’s own version of Dive’s “one shared subprocess” pattern, coexisting with the per-workspace-process pattern as an alternate transport, not a fallback within it.

The CLI-invocation layer — one binary, real path/env resolution, zero adapter registry

• build_codex_command_with_bin (app_server.rs:173-196) resolves codex_bin (per-workspace override, falling back to a global default, falling back to the literal string "codex"), normalizes Windows path quoting, and decides whether to shell out via cmd /C for .cmd/.bat scripts (should_run_via_cmd_on_windows, lines 221-238) — genuine cross-platform invocation hardening, but always for the same logical program.
• build_codex_path_env (app_server.rs:109-171) constructs a synthetic PATH by unioning the inherited environment PATH with platform-specific extra search locations (/opt/homebrew/bin, ~/.local/bin, ~/.local/share/mise/shims, ~/.cargo/bin, ~/.bun/bin, every ~/.nvm/versions/node/*/bin, or %APPDATA%\npm / %USERPROFILE%\.cargo\bin on Windows) plus the parent directory of an explicit codex_bin override — solving the “GUI apps don’t inherit shell rc-file PATH” problem that Tauri/Electron apps chronically hit, not multi-provider routing.
• check_codex_installation (app_server.rs:240-288) runs codex --version with a 5-second timeout before ever spawning app-server, surfacing “Codex CLI not found” / “Codex CLI failed to start” errors with actionable remediation text — defensive plumbing around one CLI’s presence, not a provider-selection decision point.
• No adapter registry, no provider enum, anywhere searched. grep across src-tauri/src/*.rs for claude-code, opencode, gemini-cli, amp, or any second agent-CLI binary name returns nothing; the only other “provider” concept in the codebase is nanobot’s LLMProvider trait (nanobot_bridge_daemon.rs:12,68,124) — that’s the messaging-bot layer (DingTalk/QQ) picking an LLM to answer bridge chat, wired to the same already-running codex session via a request/response bridge (OpenVibeProvider, lines 68-124), not a second coding-agent backend competing with codex for workspace sessions.

What’s inside this submodule

If you read two files: src-tauri/src/backend/app_server.rs (the actual spawn mechanism — spawn_workspace_session, WorkspaceSession, the JSON-RPC framing) and src-tauri/src/workspaces/commands.rs (connect_workspace_inner — proof the spawn is keyed and deduplicated by workspace id, with worktree inheritance for config).

Mental model for using it well

• Read “workspace” here as “one codex app-server process,” full stop — there is no session-within-workspace subdivision the way Routa has AcpManager::create_session spawning multiple independently-provider-selectable sessions per workspace. Open Vibe’s unit of process isolation and its unit of user-facing workspace addressing are the same thing.
• The swappable axis is invocation, not backend identity. codex_bin, codex_args, codex_home all resolve per-workspace with worktree-to-parent inheritance — genuinely useful for pointing different workspaces at different Codex CLI versions, config homes, or extra flags — but every one of those workspaces still runs the same underlying agent (Codex). There is no code path where workspace A runs Codex and workspace B runs a different coding agent.
• Treat the remote_backend module as a second, mutually-exclusive transport mode, not a fallback layered under the per-workspace-process model — when active, it collapses everything to one shared TCP connection, structurally closer to Dive’s single-subprocess pattern than to its own default local mode.
• Don’t confuse nanobot’s LLMProvider trait with a coding-agent adapter. It’s scoped to the DingTalk/QQ chat-bridge feature answering bridge messages through an already-running codex session — a different “provider” axis (which LLM answers bridge chat) layered on top of, not instead of, the one codex process per workspace.
• No ADRs, no docs/ARCHITECTURE.md exist in this repo — unlike Routa, there is no maintained decision log; everything above is read directly from source, and the “why” for design choices (e.g., why remote_backend exists) is not documented anywhere found in this checkout.

When NOT to reach for this

• You want evidence of genuine multi-backend/multi-provider adapter swapping. Open Vibe has exactly one coding-agent CLI wired in (codex). For that question, Routa (AcpManager::create_session, provider chosen per session call) is the study’s positive result; Open Vibe is neither a positive nor really a comparable negative — it’s a different question (process-per-workspace supervision) answered well, for one backend.
• You want a maintained decision log or architecture document. There is no docs/ARCHITECTURE.md or docs/adr/ here — reasoning has to be reconstructed from source and the README alone.
• You’re evaluating production maturity or community adoption. git shortlog shows 118 of 119 commits from a single author (citizenl) at this pin, with no ADRs, no CONTRIBUTING doc found, and one co-credited license holder who does not otherwise appear in the commit log — this is a solo hobby-scale desktop app, not a broadly-adopted or heavily-reviewed project. Treat every architectural claim here as read directly from working code, not validated by a maintainer team or community usage at scale.
• You need per-workspace concurrent, differently-configured sessions (multiple simultaneous threads against the same workspace with different models/configs). The sessions map is one entry per workspace id — reconnecting or force-respawning replaces the old process outright (commands.rs:1508-1518) rather than layering a second concurrent session alongside it.

How this compares to the rest of the study

Open Vibe’s load-bearing contribution to this study is a partial positive result, scoped narrowly: it proves that a Tauri desktop shell can cleanly spawn and supervise one real OS child process per workspace, with genuine per-workspace configuration inheritance (worktree-to-parent fallback chains for both CODEX_HOME and CLI args) — but it answers “is the process boundary real?” (yes) without answering “is the backend itself swappable?” (no; there is exactly one CLI wired in, codex). Where Routa demonstrates process isolation and backend-identity swapping together, Open Vibe demonstrates process isolation alone, cleanly, at hobby-project scale and with no adjacent decision-log documentation to lean on.

One-line summary

Open Vibe is a single-contributor Tauri 2 + Rust/Tokio desktop shell that spawns one genuine codex app-server child process per workspace — confirmed directly in spawn_workspace_session (src-tauri/src/backend/app_server.rs:290-464) and connect_workspace_inner (src-tauri/src/workspaces/commands.rs:1471-1520), with real per-workspace/per-worktree resolution of codex_bin, codex_args, and CODEX_HOME — but it is a process-per-workspace supervisor around exactly one coding-agent CLI, not a process-level adapter swap: there is no provider registry, no second backend, and no per-session multiplicity the way Routa’s AcpManager has, making it a genuine but narrower positive result than Routa and a clear step up from Dive’s single shared subprocess.