Hardcoded sandbox values always override config.toml sandbox_mode

Summary

The plugin sends an explicit sandbox value on every thread/start / thread/resume, so the sandbox_mode a user configured in ~/.codex/config.toml never applies to plugin-launched jobs. A user who sets sandbox_mode = "workspace-write" expecting delegated tasks to edit files still gets read-only unless every single invocation remembers --write; other config keys (model, reasoning effort) flow through to plugin jobs as defaults, but sandbox_mode is the one setting that silently cannot.

Evidence (at HEAD db52e28, plugin v1.0.6)

• buildThreadParams and buildResumeParams always materialize a sandbox: sandbox: options.sandbox ?? "read-only" (plugins/codex/scripts/lib/codex.mjs:68, :81) — the config value can never surface.
• Task path hardcodes the pair: sandbox: request.write ? "workspace-write" : "read-only" (plugins/codex/scripts/codex-companion.mjs:491).
• Review paths pin read-only (codex.mjs:1012, codex-companion.mjs:414).
• The app-server does fall back to config when the parameter is omitted. Verified live (Codex CLI 0.145.0-alpha.2) with a minimal JSON-RPC client:
  • thread/start with sandbox omitted → the response sandbox matched the sandbox_mode configured in config.toml, alongside the config-resolved model and reasoningEffort.
  • thread/start with sandbox: "read-only" → response sandbox: {"type":"readOnly","networkAccess":false}, overriding config as expected.

So the ?? "read-only" default and the two hardcoded call sites are the only thing standing between config.toml and plugin jobs.

Repro

1. Set sandbox_mode = "workspace-write" in ~/.codex/config.toml.
2. Run node scripts/codex-companion.mjs task --background "any prompt" without --write.
3. The job executes read-only regardless of config. There is no flag, config key, or environment variable that lets the configured sandbox_mode through.

Proposed fix

When the caller passes no explicit sandbox-affecting flag, omit sandbox from the thread params and let the app-server resolve it from config.toml — the same fallback the app-server already performs for model and reasoning effort. --write stays as an explicit override, and the review paths can reasonably remain pinned read-only if reviews are meant to be side-effect-free; that call is yours.

An alternative shape with the same effect is a --sandbox <read-only|workspace-write|danger-full-access> passthrough on task, mirroring the Codex CLI's own --sandbox flag and defaulting to today's behavior.

Happy to follow up with a PR once a direction is picked.

Related

• #145 / PR #147 — --full-access flag on task; a per-run escape hatch, complementary to (not a substitute for) honoring the configured default.
• #349 — Windows sandbox coercion; adjacent sandbox-selection behavior.
• #273 — sandbox-blocked verdicts; another symptom of sandbox policy being invisible to callers.

Environment

• Plugin codex@openai-codex v1.0.6 (upstream HEAD db52e28)
• Codex CLI 0.145.0-alpha.2
• Claude Code on WSL2 Ubuntu 26.04, Node v24.18.0

Start with buildThreadParams and buildResumeParams in plugins/codex/scripts/lib/codex.mjs, then inspect the task and review call sites in plugins/codex/scripts/codex-companion.mjs. Reproduce with the stated config.toml setting and task command, then confirm the chosen direction: configured sandbox defaults apply when no override is given, while explicit --write behavior remains correct.