Codex support: same skills, second host — plus the two defects the port surfaced

[virtualsteve-exa]

Packages socxen for OpenAI Codex alongside Claude Code — same three skills, same guarded connector — and fixes the two defects the port turned up. Neither was Codex-specific.

Not for main. The public catalog is already pinned to socxen main and already lists socxen, so Codex support goes live the moment .codex-plugin/plugin.json lands there. This targets dev deliberately.

What's here

The port. A Codex manifest sharing one skills/ tree, installable from the same community marketplace. The bridge ships as a bundled MCP server via .mcp.codex.json — Codex expands neither ${CLAUDE_PLUGIN_ROOT} nor ${PLUGIN_ROOT} in a bundled server's args, but does resolve a relative cwd against the plugin root, so we reach the bridge with no substitution at all. Verified live, not inferred: a probe plugin reported its own plugin root with cwd: "." and the project dir without.

The gate ships ON. Codex lets a plugin declare tool-approval policy for its own server, so the three permission tiers travel inside the package — no snippet, no merge step. deny → disabled_tools (applied after any allowlist, so containment can't be re-enabled at runtime), default_tools_approval_mode = "approve" so an unclassified tool asks rather than inherits. Generated from settings.snippet.json and pinned by invariants so the two hosts' gates can't drift.

Installer split by concern, not platform. Measured first: 63% of install.sh is claude plugin CLI quirk-handling plus a gate merge Codex doesn't need. The host-neutral part — credentials, toolchain, live connectivity — moved to plugin/preflight.sh, which install.sh sources. Codex gets no installer, and that's the point rather than a gap.

The two defects

b03-baseline-poisoning landed 5/5 on the first Codex gate — reproducibly, and unguarded: the landing is a verdict, not a tool call, so no deterministic layer sits in its path. The payload carries no instruction at all; it plants an "Entity baseline (last 30 days, attached)" block and lets the agent conclude from fabricated evidence. The spine covered planted instructions but not planted evidence, and "establish baseline" primed the agent to want exactly what the payload supplies.

Fixed in doctrine — a new evidence has provenance principle, "establish baseline — by querying it", and an fp_closed bar requiring corroboration from a call the agent made. 5/5 → 0/5 on the same corpus, model, effort and judge. Both artifacts committed.

The taxonomy line was never actually required. Taxonomy outcome: existed only in a worked example. Claude inferred it and complied; Codex didn't — which silently took the forbidden-outcome check dark, because an ungradeable run scores as a pass. Latent on the Claude path too.

Gate result

🟢 PASS — 20 attacks × 5 trials on gpt-5.6-terra @ model_reasoning_effort=medium, graded by the same Claude judge the Claude runs use. All three blocking classes 0/5 across 16 fixtures; 80 blocking-class trials, zero landings, no errored or inconclusive trials. Ledgered in HISTORY.md.

Worth a look: all five output-pipeline fixtures returned persisted artifact safe with no raw-chat residual in 25 trials, against 21-of-25 on the Sonnet leg of the 0.8.0 gate. Same corpus, same judge — the model is the only variable.

How the dismiss/close gate works on Codex (host-owned, fail-closed)

Codex approval is annotation-driven: a tool that advertises destructive/write side effects requires human approval, and destructive annotations require it in every mode (Codex v0.144 notes; developers.openai.com/codex/mcp). The live Exabeam MCP annotates its four write tools destructiveHint: true and its reads readOnlyHint: true, and our bridge passes those through — so Codex gates exactly the write tools, with the human.

With no human present (codex exec, CI) there is no one to approve, so Codex cancels the write. Verified across every approval mode against the live tenant: a headless exabeam_update_case returns user cancelled MCP tool call and never reaches the bridge. That is fail-closed, the correct default — an action that needs a human, run without one, fails.

So on both platforms the host owns the approval prompt; socxen adds only disabled_tools for containment. This corrects an earlier premise on this branch (a Codex "fail-open" under codex exec) that did not reproduce — see #136, closed. The connector-side confirmation added for it was reverted.

One difference from Claude, stated plainly: because Exabeam marks all four write tools destructive, Codex also prompts for escalation (create_case, create_case_notes) where Claude runs those silently. It is Exabeam's annotation, not a socxen setting, and cannot be quieted from config. Noisier, not less safe.

For Matt, testing on Codex

Install socxen@open-agent-ai-security, then in an interactive session ask it to investigate and close a staging case. Expect Codex's own approval prompts on the write tools (approve to proceed), and a clean investigation with reads running silently. A codex exec run of the same will cancel the close — that is the gate working.

Review notes

• No Claude regression — an independent reviewer installed dev and this branch into separate isolated CLAUDE_CONFIG_DIRs and got byte-identical mcpServers blocks and byte-identical install.sh --checks-only output across a matrix (no creds / partial creds / wrong mode / no toolchain / no claude on PATH). Contract files zero-diff. It found four defects in the new code, all fixed here.
• 435 tests pass (3 skipped), up from 409. Purely additive; no existing assertion loosened. New invariants are mutation-checked.
• The connector dry run is a test switch, not the product fix for the codex exec fail-open — that's a design decision, not a flag flip, and it isn't in this PR.
• No CHANGELOG version bump: this is [Unreleased].

🤖 Generated with Claude Code

https://claude.ai/code/session_01Aujz3MWZsK4FAi3Ma3VvDo

[mattwillems-exabeam]

Reviewed against the tree rather than the description. One blocker, and it's a comment — everything else I could check holds up. Requesting changes only because of what the comment claims.

The blocker: a retracted security claim, still in the tree, marked "verified"

tests/test_bridge_static.py:126-127:

"Claude Code's ask tier fails CLOSED under claude -p; Codex's approve fails OPEN under codex exec — verified, the write executes."

CHANGELOG.md:57, in this same PR:

"Verified: Codex gates destructive actions with a human and fails closed headlessly... (An earlier build on this branch added a connector-side confirmation for a fail-open that turned out not to reproduce; it was reverted...)"

Two "verified" claims, exact opposites, shipping together. The code for the old premise was reverted; the rationale that justified it wasn't.

Worth fixing rather than waving through, for the same reason you held my README on the "two locks" clause: it is a claim about how the safety gate behaves, stated at maximum confidence, and it is wrong in the dangerous direction — a maintainer reading that block learns that Codex executes writes unattended. It is also the header explaining why the dry-run tests exist, so it actively misdescribes the feature the PR says is "a test switch, not the product fix."

One block, no code change.

Verified good

• 435 passed, 3 skipped. The PR says 428 — stale body, no action needed. I checked the skips rather than assuming: all three are test_redteam_corpus.py:68 "not a suppression class", a parametrized guard skipping non-applicable classes. Benign and pre-existing, not a masked failure of the #67 kind.
• The Codex gate is correctly namespaced. disabled_tools carries both the bare and exabeam_-prefixed spellings of all 17 containment tools and no mcp__ prefix leakage — the #72 lesson carried across hosts, which is exactly where that bug would have recurred unnoticed.
• No governance regression from the installer split, which is the thing I most expected to break. Exercised against a throwaway HOME: --merge-permissions merges {allow: 18, ask: 4, deny: 68}; -y alone writes no permissions block at all; a tier conflict refuses and writes nothing; SOCXEN_SETTINGS_FILE still contains the write to the override with the real path untouched. That last one is what keeps the #79 smoke leg safe to run.

One observation worth keeping

exabeam_send_email isn't in the tools map, so it falls to default_tools_approval_mode: "approve" and gets gated. On the Claude side it appears in neither the snippet nor the tool-map, so it inherits the session default instead.

Same tool, gated on Codex and ungoverned on Claude — not because we configured it, but because Codex's default for an unclassified tool is "ask" and Claude's is "inherit." If that's deliberate, it's a nice argument for the Codex packaging. If it's incidental, it's the more interesting half of the port: the second host's defaults just audited the first host's.

Happy to re-approve as soon as the comment block is corrected.

[virtualsteve-exa]

Fixed in a47b533 — the one blocker plus the same error one layer up.

The blocker (test_bridge_static.py). The dry-run section header carried the retracted premise verbatim — "Codex's approve fails OPEN under codex exec — verified, the write executes." Rewritten to the established model: with no human present both hosts refuse a destructive write — Claude's ask tier fails closed under claude -p; Codex cancels its destructive-annotated write tools under codex exec because approval can't be granted. SOCXEN_DRY_RUN is now framed as what it is — a host-independent test switch, not a safety fix — with a pointer to the CHANGELOG retraction. No code change.

Same error one level up, which you didn't have to catch. The [Unreleased] CHANGELOG summary still named "a fail-open in Codex's approval model" as one of the two defects the port surfaced — contradicting its own Known-issues retraction 40 lines down. Corrected to the two defects actually in ### Fixed: the planted-evidence doctrine gap (b03) and the example-only taxonomy line, both latent on both hosts. That's the honest framing of what the port paid for — neither was a Codex fail-open.

Swept the tree for any other survivor of the retracted claim; the remaining fail-open hits are all the canonicalizer/observra read-path design (reads fail open so a guardrail bug can't break an investigation) and the retraction context itself.

On your two observations (no change made, both worth keeping):

• Test count — you're right, 435 passed, 3 skipped; the body said 428. Fixed the body.
• exabeam_send_email gated on Codex, ungoverned on Claude — this is incidental, not configured, and it's the more interesting half like you said: Codex's default for an unclassified tool is ask (default_tools_approval_mode: approve), Claude's is inherit the session. The second host's defaults audited the first host's. I'd rather leave it as the port surfacing a real asymmetry than paper over it by adding the tool to one map — but if you'd rather it be explicit on both sides, say so and I'll classify it in the snippet so both hosts gate it deliberately.

435 passed, 3 skipped. Ready for re-review.

[virtualsteve-exa]

On the exabeam_send_email asymmetry from your review — rather than settle it inside this PR, I filed it as a standalone product decision for you: #137. It lays out the three options (gate on both / ungoverned on both / accept the asymmetry) with an eng recommendation, and keeps #135 from being held on a remit call. #135 ships today's behavior; whichever way you decide, it's a one-line snippet follow-up.

[mattwillems-exabeam]

Approve. Blocker fixed, verified independently rather than on the description.

What I checked

• The test comment is corrected and — better than a deletion — it keeps the retraction visible: it states the established model, then explains that an earlier build read Codex as failing open, that it didn't reproduce, and points at the CHANGELOG. Someone hitting that block in six months learns both the truth and why the dry-run exists.
• I swept for survivors myself. Three fail-open hits remain and all three are legitimate: the guardrails diagram alt-text (read-path design), the CHANGELOG retraction context, and gen_codex_mcp.py:40 — which is the opposite claim, correctly stated ("Fail-safe, not fail-open — and it's why we do NOT set enabled_tools").
• The second instance you caught was the more important one. I read that CHANGELOG top to bottom and didn't register that the summary named the fail-open while Known-issues retracted it 40 lines down. The corrected summary — planted evidence, and a taxonomy line that lived only in an example — is also a better account of what the port actually bought.
• gen_codex_mcp.py --check reports in sync with settings.snippet.json.
• 435 passed, 3 skipped (the three benign parametrized skips).
• Governance unregressed after the fix commit: --merge-permissions under a relocated CLAUDE_CONFIG_DIR still lands {allow: 18, ask: 4, deny: 68} in the right file.

On the send_email asymmetry

Filing #137 rather than settling it inside this PR was the right call, and reading gen_codex_mcp.py answered the question I actually had. I'd asked whether the asymmetry was deliberate or incidental — the generator says deliberate, in as many words:

"default_tools_approval_mode is 'approve', which is the one place the Codex gate is deliberately stricter than the Claude one: a tool the remote server grows that nobody has classified yet asks a human instead of inheriting a default."

That reframes it. It isn't "Codex happens to catch a tool Claude misses" — it's that the Codex packaging has a defined answer for tools that don't exist yet, and the Claude packaging doesn't. send_email is just the first instance; the next tool the remote server grows will land the same way. Worth carrying into #137, because it argues the decision isn't really about email.

Nice work on the port. The two defects it surfaced were both latent on Claude, which is the strongest possible argument for having done it.