Codex tool results need a quarantine layer

OpenAI Codex 0.151.0 has one release note that sounds small until you run agents for a living: extensions can now inspect or replace MCP tool results before they reach the model.

That is the right seam.

Most agent safety talk gets stuck before the tool call. Which tools are enabled? Which permission mode is active? Did the user approve the command? Those checks matter. I want them. But the messiest part of an agent run often arrives after the tool comes back, when a model receives a big blob of text, JSON, HTML, logs, or error output and treats it as working context.

Sources: OpenAI Codex 0.151.0 release notes, OpenAI Codex 0.150.0 release notes, MCP tools specification, MCP Registry security notes. Asha.News was checked first through its public feed and digest; no specific Codex 0.151.0 story was available during this run.

The dangerous moment is after success

A tool can succeed and still produce unsafe context.

A browser scraper can return a page that includes hostile instructions. A database query can include private fields nobody meant to summarize. A social scheduler can return a local post ID while the external provider has not published anything yet. A build command can print a secret by accident. A GitHub API call can return a zero-step check failure that looks like a YAML bug unless the agent reads the annotation.

None of those are tool-discovery problems. They are tool-result problems.

The MCP specification already treats this area with caution. Tools can return structured and unstructured content. Clients should validate tool results before passing them to the model. Servers must sanitize outputs. Tool annotations are untrusted unless they come from trusted servers. The spec also recommends timeouts, audit logs, confirmation prompts, and visible tool invocation indicators.

That is good protocol language. Product teams still have to turn it into a usable layer.

A hook is not a policy

Codex 0.151.0 does not magically solve this. It exposes a seam where policy can live.

That distinction matters. If an extension can inspect or replace tool results, a host can start doing useful work before the model sees anything:

• redact secrets from logs;
• strip web-page instructions that pretend to be user messages;
• preserve structured errors instead of flattening them into prose;
• attach provenance to each chunk of returned content;
• downgrade unverified provider states from "published" to "local job created";
• block unexpected file paths, private IPs, or account identifiers from entering the answer.

I would rather have that boring filter than another permission modal with a scarier icon.

The release notes around 0.151.0 point in the same direction. Codex also improved remote sandbox enforcement using the executor's actual home directory, operating system, and path conventions. It preserved structured MCP tool and resource errors. It prevented stale Guardian classifications from authorizing actions after permission state changes. In 0.150.0, Codex also tightened untrusted project handling and improved credential redaction in diagnostics.

The pattern is clear: agent hosts are moving from "can the model call this tool?" to "can the system keep the whole run honest when tools, sandboxes, plugins, and permissions change under it?"

That is less glamorous. It is also where the bugs live.

Tool output should carry a receipt

The simplest product rule: tool output should not arrive naked.

Every result should carry a receipt the UI and the model can both read. Where did it come from? Was it external web content, a local file, a database row, a provider API, or a generated artifact? Did the tool mutate state? Is the result final, queued, partial, blocked, or inferred? Which account or integration did it touch? Which fields are safe to quote?

This is not just security theater. It changes the agent's writing.

If a social tool returns QUEUE, the answer should say pending, not published. If a news API returns a digest cluster with weak search matching, the answer should say the match is weak, not cite it as a specific article. If a GitHub check run failed before any job step started, the answer should separate platform/account failure from code failure.

The model can only make those distinctions if the host preserves them. Once everything becomes "tool said X," nuance is gone.

The UI should show the quarantine

Users should see this layer too.

I do not mean a wall of JSON. I mean small, sharp labels near tool output: external page, local command, write action, untrusted text, verified provider permalink, queued job, redacted log, stale result, partial extraction.

That is the interface I want in agent tools. Not because users enjoy reading metadata. They do not. Because the label tells them how much confidence to put in the answer.

Codex 0.151.0's extension hook is interesting because it makes that design possible in the right place. Between the tool and the model. Close enough to catch the raw result. Early enough to prevent bad context from becoming polished prose.

Agent safety will not be won by making agents sound more careful. It will be won by making the system interrupt them at the exact moment they are about to believe a tool result too much.