Plugin overrides Codex sandbox config and can trigger bwrap failures

Summary

The plugin currently passes an explicit sandbox mode when starting Codex app-server threads:

• native review starts with sandbox: "read-only"
• adversarial review starts with sandbox: "read-only"
• task/rescue starts with sandbox: "read-only", or "workspace-write" when --write is used

That means a user-level Codex config such as:

approval_policy = "never"
sandbox_mode = "danger-full-access"

is not honored for plugin-launched threads. On Linux systems where bubblewrap cannot initialize, plugin commands can still fail with bwrap errors even though plain codex uses danger-full-access.

Reproduction

1. Configure Codex with sandbox_mode = "danger-full-access".
2. Use /codex:review or /codex:rescue --write through the Claude Code plugin.
3. Observe that the plugin-created thread receives a sandbox override and may enter the Linux bwrap sandbox path.

On an affected machine this manifests as errors like:

bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted
bwrap: setting up uid map: Permission denied

Expected behavior

The plugin should inherit the effective Codex sandbox configuration unless it has a user-visible reason to override it. This matches the README wording that the plugin uses the user's existing Codex configuration.

Notes

I have a patch ready that omits the sandbox field from app-server thread/start and thread/resume requests unless an explicit override is provided, plus regression coverage for review and task --write.

Start by locating the plugin code that constructs app-server thread/start and thread/resume requests, then reproduce with sandbox_mode set to danger-full-access. Compare review and task --write paths; done means sandbox is omitted unless explicitly overridden, with regression coverage for those paths.