Multiple parallel codex exec instances interfere via shared session restore

Bug Description

When running multiple codex exec instances in parallel (e.g., via a batch runner or concurrent terminal sessions), the instances interfere with each other by triggering session restore from shared state.

Steps to Reproduce

1. Launch 2+ codex exec --full-auto processes concurrently, each with a different prompt:

# Terminal 1
codex exec --full-auto -m gpt-5.2 "task A prompt"

# Terminal 2 (simultaneously)
codex exec --full-auto -m gpt-5.2 "task B prompt"

Or via a batch runner that spawns multiple codex exec subprocesses in parallel.

1. Observe that one or more instances will attempt to restore a session from another running instance, corrupting each other's execution context.

Expected Behavior

Each codex exec invocation should be fully isolated. Parallel instances should not share or interfere with each other's session state.

Actual Behavior

Parallel instances detect each other's session files (likely in ~/.codex/) and attempt to restore from them, causing:

• Wrong context being loaded (prompt from instance A appears in instance B)
• Unexpected session resume prompts
• Non-deterministic failures in batch/CI workflows

Environment

• Codex version: 0.98.0 (installed via @openai/codex)
• OS: macOS 15.2 (arm64)
• Node: v25.x
• Shell: zsh

Suggested Fix

codex exec should either:

1. Use a per-process unique session directory (e.g., ~/.codex/sessions/<pid>/ or a random tmpdir)
2. Skip session restore entirely when invoked with --full-auto or exec subcommand (non-interactive mode should be stateless)
3. Use file locking or atomic session IDs to prevent cross-instance reads

This is especially important for CI/CD pipelines, batch runners, and automated workflows where parallel execution is the norm.