codex_app MCP thread tools should inherit project and session execution settings

Feature request

The new codex_app MCP tools should preserve or inherit the effective configuration of the current task and destination project when creating, forking, or handing off tasks.

Problem

Before the move to MCP-backed codex_app tools, tasks created through the Codex app generally continued using the active task's model, reasoning, approval, and sandbox configuration.

With tools such as:

• mcp__codex_app.create_thread
• mcp__codex_app.fork_thread
• mcp__codex_app.handoff_thread

new or transferred tasks can start with different settings.

create_thread exposes optional model and thinking parameters, but it has no parameters for the approval policy, sandbox mode, or permission profile. When parameters are omitted, the resulting task may use defaults that differ from both the current task and the selected project.

This is particularly disruptive when working with agents inside connected devcontainers. My devcontainers intentionally run without an additional Codex sandbox. A task created or taken over through the MCP tools may instead start with incompatible sandbox and approval settings.

The usual workaround is:

1. Let the agent create or take over the task.
2. Notice that it is using different execution settings.
3. Cancel the task.
4. Tell the agent to continue using the current task's approval and sandbox configuration.

This makes cross-project and multi-agent workflows less reliable than they were with the previous app-native tools.

Suggested API

A backward-compatible option could be an optional configuration object:

settings?: {
  inheritFrom?: "auto" | "project" | "source_thread" | "global";
  approvalPolicy?: string;
  sandboxMode?: "read-only" | "workspace-write" | "danger-full-access";
  permissionProfile?: string;
}

Existing model and thinking parameters could remain explicit overrides.

inheritFrom: "auto" could be the default:

• create_thread: resolve the destination project/host baseline.
• fork_thread: inherit from the source task.
• handoff_thread: preserve the source configuration and reconcile it with destination requirements.
• Projectless tasks: inherit from the calling task where possible.

The exact API is less important than ensuring omission means "inherit the relevant effective configuration," rather than "select potentially different defaults."

Start by tracing the codex_app MCP entry points named in the issue: create_thread, fork_thread, and handoff_thread. Compare how each currently resolves model, thinking, approval, sandbox, and permission settings for source and destination tasks. Done means omitted settings inherit the relevant effective configuration without breaking existing explicit overrides, with coverage for projectless and cross-project workflows.