Tool-backed sessions cannot prove active root model and reasoning effort

Summary

A tool-backed Codex session cannot expose authoritative, parent-visible metadata proving the effective model and reasoning effort of the active root thread.

This makes fail-closed multi-agent orchestration impossible when a workflow requires an exact root model/effort before spawning custom agents. A project config can describe the intended model, but it does not prove what the already-running root thread is actually using.

In my case this caused five restart/preflight loops since the previous evening.

Environment

• Surface: tool-backed Codex session / collaboration tools
• Codex CLI: 0.144.5
• OS: macOS 26.5.2
• Architecture: arm64
• Multi-agent enabled
• Intended root: gpt-5.6-sol / high
• Project-scoped custom agents under .codex/agents/*.toml

Minimal configuration

# .codex/config.toml
model = "gpt-5.6-sol"
model_reasoning_effort = "high"

[agents]
max_threads = 4
max_depth = 1
interrupt_message = true

Custom agent profiles parse correctly and specify role-specific model, effort, sandbox, and developer instructions.

Reproduction

1. Create the project config above.
2. Add valid project-scoped custom agent TOMLs under .codex/agents/.
3. Start a tool-backed Codex session in the trusted project.
4. Require the root orchestrator to prove that the active thread is gpt-5.6-sol/high before spawning agents.
5. Run:

$ codex doctor --json

Relevant result:

{
  "config.load": {
    "status": "ok",
    "details": {
      "model": "gpt-5.6-sol",
      "model provider": "openai"
    }
  }
}

The report does not expose the active thread's effective reasoning effort, nor does it prove that the already-running thread was created from the currently loaded project config.

1. Run:

$ codex debug prompt-input "probe custom agent discovery"

This renders model-visible prompt messages. It does not provide an authoritative runtime receipt for root model/effort or a discovery result for project-scoped agent profiles.

1. Inspect the tool-backed collaboration surface:

spawn_agent exposes only:

• task_name
• message
• fork_turns

list_agents exposes path/status/task data, but not the effective role, model, reasoning effort, sandbox, or profile provenance.

Actual behavior

The orchestrator can prove:

• the TOML parses;
• the requested models exist in the bundled catalog;
• the project is trusted;
• the configuration says gpt-5.6-sol/high.

It cannot prove:

• the active root thread is actually using that model and effort;
• which configuration layer produced the active root;
• whether project-scoped custom profiles are discoverable through the current tool-backed spawn surface;
• the effective role/model/effort/sandbox of a spawned child.

A fail-closed workflow therefore has two bad options:

1. stop and request another restart indefinitely;
2. trust configuration intent as if it were runtime evidence.

Expected behavior

Expose a canonical runtime receipt for the active root thread, available to the parent and diagnostic tooling:

thread_id
effective_model_provider
effective_model
effective_reasoning_effort
effective_sandbox
config_provenance
project_config_loaded
custom_agent_profiles_discovered
multi_agent_version

For child spawns, return the resolved profile plus effective model/effort/sandbox, and fail explicitly when the requested profile cannot be selected.

codex doctor --json should clearly distinguish:

• configuration intent;
• active runtime state;
• values that cannot be verified.

Why this is operationally significant

Model/effort and sandbox selection are not cosmetic in an orchestrated workflow. They can be hard gates for:

• read-only versus writer roles;
• independent verification;
• cost/latency allocation;
• audit trails;
• preventing silent fallback;
• deciding whether implementation is authorized to start.

Without authoritative runtime metadata, strict orchestration specs become restart loops rather than executable controls.

Related issues

• #32291 — tool-backed Desktop cannot select named custom agents
• #32504 — canonical subagent activity omits effective identity/model/effort
• #33314 — full-profile application and lifecycle continuity
• #28113 — reasoning effort startup behavior

This report is specifically about root-thread runtime observability and preflight proof, before the first child is spawned.