Mistral Vibe v2.15.0 Puts Policy Hooks Where Coding Agents Actually Need Them

The useful safety features in coding agents are rarely the ones that look like safety features. They look like hooks, queues, refusal messages, boring permission defaults, and compaction behavior that preserves the original task instead of letting the agent slowly drift into jazz.

That is why Mistral Vibe v2.15.0 is more interesting than its release-note footprint suggests. The headline addition is experimental before_tool and after_tool hooks: shell scripts declared in hooks.toml that fire around every tool call. Hooks can deny a call, rewrite tool inputs, or append context to tool output, and they require explicit opt-in with enable_experimental_hooks = true. That sounds like plumbing. It is also the place where agent governance actually becomes enforceable.

The release landed on June 12, 2026 at 11:19:54 UTC, according to the GitHub release metadata. It shipped 10 release assets and, at research time, the repository had roughly 4,453 stars, 531 forks, and 271 open issues. The comparison from v2.14.1 to v2.15.0 shows one release commit touching 247 files, including changelog, README, ACP hook tests, session deletion tests, CLI tests, binary build scripts, and adapter tests. That test surface matters. Hook systems are easy to announce and hard to make predictable.

Policy belongs at the tool boundary

A coding agent's most consequential decisions happen right before and right after tools run. Before it executes a shell command. Before it edits a file. Before it calls an MCP server. After it reads a suspicious blob of web content. After it gets a huge tool result that might drown out the original instruction. If teams cannot intercept those moments, they end up trying to encode operational policy in a long instruction file and hoping the model remembers. That is not governance. That is a sticky note on a chainsaw.

Vibe's hooks move policy closer to the place where risk appears. A before_tool hook could block writes outside the workspace, reject shell commands matching dangerous patterns, prevent reads of known secret files, or require a narrower command when the agent reaches for a broad one. An after_tool hook could append local policy context after a docs lookup, redact known-sensitive output before it re-enters the model context, or annotate a command result with team-specific warnings. None of that requires the model to be morally inspired in the moment. It requires the runtime to expose a programmable seam.

The catch is equally obvious: hooks are shell scripts. Shell scripts are powerful, portable enough to be dangerous, and often maintained with the institutional discipline of a forgotten cron job. Mistral is right to mark the feature experimental. The responsible path is not to immediately write a 900-line policy monster. Start with an audit hook that logs tool name, path, command, and decision. Then add one deny rule for writes outside the repo. Then add one rule for sensitive files. Treat hook changes like production code: review them, test them, and keep them small enough that a tired engineer can understand the failure mode.

The release also tightens the contract for post-agent-turn retries. Experimental hooks no longer use exit code 2 to trigger retries; hooks must now exit 0 and return structured JSON like {"decision":"deny","reason":"..."} on stdout. Exit code 2 is treated as failure. Good. Exit-code folklore is how local tools become haunted. If a hook is denying a tool call or forcing a retry, the runtime should receive a parseable decision and a human-readable reason. Agent infrastructure needs fewer magic conventions and more explicit protocols.

The human loop gets less brittle

The second useful addition is message queueing. Messages typed while the agent or a !bash command is running are queued and shown above the input. Esc pauses the queue, Ctrl+C drops the last queued message, and Enter flushes the queue when paused. This is not glamorous, but anyone who has used a terminal agent for real work knows the problem: you remember a constraint thirty seconds after launching the task. Without queueing, you either interrupt useful work, wait and hope you remember, or paste the correction into a context that has already moved on.

Queueing gives the human a less destructive way to steer the session. That matters because coding agents are increasingly long-running collaborators, not answer machines. Mistral's broader Vibe positioning makes that explicit: the company describes Vibe as one agent for long-running, multi-step work across productivity and coding, with Work and Code modes, remote coding sessions, GitHub-connected projects, isolated sandboxes, diffs, and a VS Code extension using the same harness as the CLI. In that world, interaction design is not decoration. It is part of correctness. If the operator cannot insert constraints without blowing up state, the agent will make avoidable mistakes.

Vibe v2.15.0 also collapses tool result output by default and shows URLs or search queries at a glance for collapsed web output. Again, this is small and practical. Agent transcripts become unreadable fast. Collapsing output keeps the conversation scannable while preserving inspection paths. The right default is not “hide evidence”; it is “make evidence available without forcing every grep result and web response into the main narrative.”

Compaction is where agents forget what they promised

The release's compaction change may be the most underrated item: Vibe now re-injects prior user messages so the agent retains the original task goals across context resets. Long coding tasks often fail not because the model cannot write the next function, but because the original request has fallen out of the visible context and the agent starts optimizing for the last local fragment. It fixes the test but forgets the migration constraint. It edits the module but forgets the compatibility requirement. It follows the latest warning and loses the reason the work started.

Re-injecting prior user intent is not a complete solution, but it attacks the right failure mode. Teams evaluating coding agents should test this directly. Give the agent a task with three constraints, force or wait for compaction, then see whether the final patch still satisfies all three. Most benchmark discussions focus on whether agents can solve isolated tasks. Daily engineering work is worse: long context, partial progress, contradictory signals, and constraints that matter precisely because they are easy to forget.

Surfacing model refusal stop reasons is in the same category of boring runtime quality. Silent stops are poison. A visible refusal tells the operator what to change: narrow the task, switch models, reduce sensitive context, inspect policy, or stop because the agent is correctly refusing something risky. Debuggable failure beats mysterious failure every time.

The one default I would watch carefully is automatic approval for common read-only shell commands like ls, cat, and pwd. It improves flow; asking permission for every directory listing is a productivity tax with no constituency. But read-only does not mean harmless. cat .env is read-only. Listing a client directory is read-only. Dumping local config into the model context is read-only. The safety of this default depends on trust-folder behavior, file and directory permissions, and exactly the hook system this release introduces. Fast exploration and serious safety are only compatible when teams can encode local exceptions.

The practical advice: upgrade only after testing the hooks in a disposable repository. Enable experimental hooks, log every tool call, and write one narrow deny rule. Test queued messages during a running shell command. Run a long task through compaction and check whether the initial requirements survive. If you use MCP, pay attention to the new per-server [mcp_servers.auth] configuration block and verify credentials are scoped the way you expect. If you use ACP integrations, note that max_turns is now exposed through set_config_option, which gives orchestrators another useful budget control.

Mistral Vibe is still smaller than the OpenCode/Codex/Claude Code gravity wells by public GitHub attention. But this release points at the right battlefield. The next wave of coding-agent quality will not be won only by model benchmarks. It will be won by runtimes that make tool calls inspectable, policy programmable, context resets less lossy, refusals visible, and human steering less brittle. That is not the shiny part of agent demos. It is the part teams actually live with on Wednesday afternoon.

Sources: GitHub release — mistralai/mistral-vibe v2.15.0, Mistral Vibe repository, Mistral — Vibe gets to work