A bounded Codex configuration bridge in a Rust desktop agent

[bobleer]

A bounded Codex configuration bridge in a Rust desktop agent

Disclosure: I maintain BitFun. I'm sharing this for configuration/interoperability feedback; this is not a Codex port or a claim of full Codex compatibility.

BitFun is a Rust/Tauri desktop agent that can discover Codex configuration left in user and project scopes. The design goal was to reuse the parts whose behavior we can preserve, while refusing to silently reinterpret the rest.

The current boundary is:

• Agents: BitFun reads the supported subset of user/project [agents] declarations and role files. Codex roles remain subagents; model and reasoning-effort requests must resolve to an existing model configuration or an explicit user binding. Unsupported behavior fields block or downgrade activation.
• MCP: supported stdio and HTTPS Streamable HTTP declarations can be consumed as continuously compatible sources; discovery does not start a server, and first activation follows BitFun's normal MCP approval flow. A separate snapshot-import path copies only declarations with equivalent native semantics; it does not copy credentials, headers, environment values, or cwd, and imported entries start disabled with autostart off.
• Hooks: static Codex hook declarations first appear as a redacted, read-only catalog. Only a supported synchronous command subset can be copied into BitFun's native hook layer, after the user reviews the exact command. Async, non-command, unknown, or activation-dependent handlers are not executed.
• Activation: background discovery is separate from activation. Subagents and MCP servers that expand executable capability remain subject to source preferences and the existing confirmation flow. Invalid higher-precedence configuration does not silently revive a lower-precedence definition.

This is deliberately narrower than runtime compatibility. BitFun does not launch Codex through this adapter, resume Codex sessions, infer plugin/managed/session-provided state, or pretend every Codex field has an equivalent. The Codex runtime adapter and external-session continuation remain future work.

Pinned implementation references:

• compatibility scope and explicit limits
• Codex agent source
• Codex MCP source
• Codex hook source

Two questions for Codex users and maintainers:

1. For downstream tools, should an unknown behavior-affecting field block activation, or is there a documented class of fields that is always safe to ignore?
2. Which user/project configuration semantics are intended to be stable enough for cross-client consumption rather than only for Codex itself?