Repository navigation
feat(team): add mistral worker type via vibe CLI - #2846
siennathesane wants to merge 1 commit into
Conversation
Wire mistral/vibe support across both team runtimes (CLI-pane and MCP-bridge spawn path), bringing it to feature parity with claude, codex, and gemini workers. Vibe is Mistral's agentic CLI with `-p` prompt mode and `--agent auto-approve` for tool autonomy. Source changes: - Extend CliAgentType union to include `mistral`; add vibeContract to model-contract with prompt-mode + auto-approve agent profile - Propagate through capabilities, scaling, status display, stage router, worker bootstrap/restart, MCP bridge spawn args - Bridge-entry validation, ask CLI provider matrix, doctor team routing, config loader provider validation - Worker overlay emits `Agent-Type Guidance (mistral / vibe)` block Test parity: - 21 existing test files extended (gemini patterns mirrored for mistral) - 1 new vibe-preflight test mirroring runtime-v2.gemini-preflight - Coverage spans launch argv, prompt-mode flow, role routing, status dedup, registration, restart preservation, capability ranking Field-validated end-to-end: `omc team 1:mistral "..."` against real vibe install — pane spawned, claim-task / transition-task-status round-tripped through CLI runtime, task completed in 18s. Constraint: vibe rejects `--model` as unknown flag — model selection happens via `--agent` profile in ~/.vibe/agents/<name>.toml Rejected: push `--model` in MCP-bridge mistral spawn path | vibe refuses to start with unknown flags Confidence: high Scope-risk: moderate Directive: when adding a 5th worker type, mirror the mistral pattern in worker-canonicalization, model-contract, capabilities, and worker-bootstrap simultaneously — partial wiring causes silent rejection at the MCP bridge layer Not-tested: long-running tasks (>5min) under vibe auto-approve mode; vibe behavior under prompt-mode startup-evidence wait window (currently 750ms — too short for vibe boot)
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: feec12c8ce
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| ].join('\n'); | ||
|
|
||
| const ASK_PROVIDERS = ['claude', 'codex', 'gemini'] as const; | ||
| const ASK_PROVIDERS = ['claude', 'codex', 'gemini', 'mistral'] as const; |
There was a problem hiding this comment.
Adding mistral to ASK_PROVIDERS makes omc ask mistral ... pass argument validation here, but askCommand then calls scripts/run-provider-advisor.js, whose PROVIDER_BINARIES/parseArgs still only accept claude, codex, and gemini. As a result, every mistral ask run fails immediately with usage/error, so this newly advertised provider path is currently broken end-to-end.
Useful? React with 👍 / 👎.
|
Thanks for the PR. Closing this as submitted because it targets If you want to continue this, please reopen as a smaller PR against — |
2 participants
Summary
mistralas the 4th tmux worker type alongsideclaude,codex,gemini, and the recently mergedcursor-agentvibeagentic CLI through both team runtimes (CLI-pane viaomc team N:mistraland MCP-bridge spawn path)gemini(22 test files, including a newruntime-v2.vibe-preflight.test.ts)Why mistral / vibe
Mistral's
vibeCLI matches the agentic-CLI contract OMC already uses for claude/codex/gemini: persistent worker process, prompt-mode entry, autonomous tool execution under an--agentprofile. Codestral 2 (the default model behindvibe) is competitive with Sonnet for code transforms, and Mistral Pro subscribers can use it without per-token cost concerns — making it a useful fan-out option for teams that want extra parallelism without burning Anthropic quota.What's wired
CliAgentTypeextended;vibeContractadded tomodel-contract.ts(binaryvibe,-pprompt mode,--agent auto-approve, no--modelflag)runtime.ts/runtime-v2.tsand MCP-bridge spawn viamcp-team-bridge.ts### Agent-Type Guidance (mistral / vibe)block emitted in worker overlayskills/omc-teams/SKILL.mdupdated to list mistral as a worker optionTest parity
it(...)blocks mirroring the gemini pattern)src/team/__tests__/runtime-v2.vibe-preflight.test.tsmirroring the existing gemini-preflight testTest surface includes: launch argv, prompt-mode flow, role routing, status dedup, registration, restart preservation, capability ranking, MCP bridge spawn args.
Field validation
End-to-end smoke tested against a real
vibeinstall:Vibe spawned with
--agent auto-approve -p '<inbox-pointer>', read the worker inbox, calledomc team api claim-task, did the work, calledomc team api transition-task-status, exited cleanly. Total elapsed: 18s.One known gotcha (not blocking)
The leader's prompt-mode startup-evidence wait at
runtime-v2.ts:705-718is3 attempts × 250ms = 750ms, which is shorter than vibe's boot-to-first-API-call latency. The worker still completes successfully, but the leader emits a one-timestartup_manual_intervention_required:<worker>:mistral_startup_evidence_missingevent on each start. Functional impact: zero (worker keeps running and finishes). Suggested follow-up: bump the wait window for prompt-mode agents, or add per-agent overrides. Happy to land that in a follow-up PR.Test plan
npm run typecheck— cleannpx vitest run src/team/__tests__/— 887 / 891 pass; 3 pre-existing failures ingit-worktree.test.tsunchanged from baseline (zero mistral content)bridge/,dist/) deliberately omitted from this PR per the cursor-agent precedent (feat(team): add cursor-agent as 4th tmux worker type (executor-only) #2736); maintainer's release pipeline regenerates them