Mistral Vibe

Vibe runs as the local user with that user's full authority and does nothing to narrow it: every shell command inherits the complete process environment, including any provider API keys and cloud or Git credentials the user has exported. There is no per-tool identity or credential scoping; the only thing standing between a hijacked model and the user's accounts is the approval prompt on shell and network tools. The Mistral API key is kept in the OS keyring by default, which is good hygiene, but it is not a scoping control.

Vibe has a careful approval system: shell commands are parsed with a real Bash grammar, compound commands are split and each part checked, dangerous options on otherwise read-only commands (find -exec, sort -o, git pager and config helpers) force a prompt, and the prompt shows the exact command. MCP tools, custom tools and sub-agent calls all pass through the same gate. However, the default agent profile auto-approves every file write and edit inside the project, so unattended edits are not fully contained by the approval and workspace-trust controls. An environment variable or config key also disables approval without a dedicated flag.

File tools resolve paths and check them against the workspace roots, prompt for anything outside, and treat .env files as sensitive; web_fetch approves per origin and refuses redirects to a different origin. But the central tool is a general shell that accepts any command string, there is no block on internal or metadata addresses, and the default tool set includes write, shell and network tools together. The model also chooses its own shell timeout with no upper bound.

There is no sandbox. Shell commands, hooks, custom Python tools and MCP servers all run directly on the host as the user, with the full environment and full network access. The approval prompt decides whether a command runs, but once it runs nothing contains it, and commands that look read-only (or a test runner the user approves) execute whatever the repository contains.

Content from web pages, repository files and MCP tool results enters the conversation with the same standing as the user's instructions; nothing tracks where content came from. What limits a hijacked agent is the general approval prompt: shell, web fetch to a new origin, web search and MCP calls all ask the user. File edits inside the project do not, and persistent agent configuration is not protected from unattended edits.

Vibe has a real workspace-trust step: project config, hooks, custom tools, skills, agents and AGENTS.md from a repository are ignored until the user trusts the folder, and the trust prompt lists the files it found. After that decision, however, project configuration is not integrity-protected, so poisoned project configuration can persist.

Vibe loads three kinds of third-party code: MCP servers launched from config, custom Python tool files, and skills. None is pinned or integrity-checked. Custom tool files from the user's directory or a trusted project's .vibe/tools are imported straight into Vibe's own process at startup, with all its credentials. MCP stdio servers run as separate processes; the MCP SDK gives them a reduced default environment unless config supplies one. A trusted project can add any of these.

The Mistral API key is stored in the OS keyring by default (falling back to ~/.vibe/.env), crash reports drop local variables and scrub paths, telemetry events carry metadata rather than prompt or tool content, and session transcripts are written owner-only. Reading .env files needs approval. But nothing redacts secrets from tool output before it goes to the model or into the transcript, the shell inherits the full environment (including any exported keys), and telemetry is on by default.

Every session is recorded as a JSON-lines transcript of all messages, including each tool call and its result, under ~/.vibe/logs/session with owner-only permissions, flushed and fsynced after every model step. Sub-agent sessions are linked to the parent tool call. The record is outside the project folder, but the agent's shell could still edit it (with an outside-workdir approval), it is not tamper-evident, and approval decisions go to the log and telemetry rather than as structured fields in the transcript.

Turn, cost and token limits exist but only apply in programmatic (-p) mode; the default interactive session has no step, time or spend ceiling. Shell commands default to a 5-minute timeout, but the model can ask for any longer timeout. Stopping works well: Escape cancels the turn and running shell commands are killed with their whole process group. Sub-agents cannot spawn further sub-agents.