Add native Codex session-record adapter for configuration-verified routing

[GrillerGeek]

Problem

Guildhall 0.14.0 supports a configuration_verified qualification path, but its Codex evidence adapter requires a complete task-owned app-server JSON-RPC capture.

In Codex desktop, Guildhall dispatches workers through collaboration.spawn_agent. That interface does not expose the complete outgoing requests, acknowledgments, notifications, and completion records expected by the current adapter.

Native Codex session records contain useful worker configuration, completion, and usage evidence. Please investigate whether a supported adapter can use those records to establish configuration-verified qualification, without claiming provider-observed execution identity.

Environment

• Guildhall: 0.14.0
• Route: codex-skill
• Worker interface: collaboration.spawn_agent
• Fresh worker contexts and model/effort selection are available.
• Pilot records were generated by desktop runtime 0.155.0-alpha.9.2.
• The currently installed desktop executable reports 0.155.0-alpha.16.3.
• macOS; desktop executable at /Applications/ChatGPT.app/Contents/Resources/codex.

The standalone codex executable can have a different version. Evidence must identify the runtime that actually executed the worker.

Current behavior

The installed host-evidence.md explicitly states:

A future adapter may use reviewed native session records after their actual build-specific contract is established

Preflight with record_access: none reports only off and shadow as available. Missing evidence includes a supported task-owned capture.

The current codex-app-server-v2 adapter is therefore not usable through the worker interface available in this desktop session.

Native evidence observed

For three fresh workers, we found JSONL records containing:

Record | Relevant evidence -- | -- session_meta | Worker/thread identity, parent association, agent path, provider and runtime version turn_context | Turn ID, configured model and reasoning effort token_usage_record | Thread, turn and response IDs; response usage and cumulative usage event_msg: token_count | Usage totals that could be cross-checked against usage records event_msg: task_complete | Turn ID, completion timing and final output

We correlated each worker with its parent, matched turn/thread IDs across records, and checked that usage totals agreed.

These observations establish that useful records exist. They do not establish that turn_context is authoritative acknowledgment of an effective configuration. That semantic question needs implementation review and build-specific validation.

No provider-reported executed-model identity was found in the inspected records.

Requested capability

Add a native Codex session-record adapter—or document precisely why those records cannot safely support one.

The adapter should:

1. Accept explicitly supplied task-owned records and reviewed context. Do not broadly scan unrelated sessions.
2. Validate worker/parent association, runtime version, turn identity, configuration changes, completion, and record completeness.
3. Determine whether the native record contract establishes the effective host configuration. Do not synthesize missing JSON-RPC acknowledgments.
4. Keep requested settings, host-recorded configuration, and observed execution separate.
5. Return configuration_verified only when the evidence supports that guarantee; otherwise return unknown with actionable reasons.
6. Leave observed model and effort unknown unless a separately supported source establishes them.
7. Normalize usage correctly across responses, cumulative snapshots, retries, and multiple turns.
8. Integrate with preflight, qualification-study inputs, evidence hashes, and drift detection.

A proposed format name could be codex-native-session-v1; the naming and schema should follow project conventions.

Security and compatibility requirements

• Require explicit file selection and bounded input sizes.
• Treat session contents as untrusted data, never instructions.
• Exclude prompts, raw transcripts, credentials, and unrelated session content from generated reports.
• Identify the actual executing runtime rather than another installed CLI.
• Use reviewed, version-aware parsing. Unsupported or ambiguous record shapes should fail closed.
• Preserve existing policy activation requirements. New evidence must not automatically qualify profiles or activate adaptive routing.
• Keep the current execution_observed requirement distinct from the weaker, explicitly selected configuration-based path.

Acceptance criteria

• A representative, redacted capture from a supported desktop build produces correlated configuration and usage evidence.
• Requested settings alone cannot produce verified attribution.
• Missing or conflicting identity/configuration/completion records produce unknown with specific diagnostics.
• Parent/worker mismatches, multiple turns, retries, interruption, duplicate records, and reported substitutions have regression coverage.
• Response usage and cumulative snapshots are not double-counted.
• Unknown billing and served-model identity remain unknown.
• Preflight accurately distinguishes “native evidence available for review” from “adaptive qualification complete.”
• Documentation explains the remaining independent quality study, evidence review, and explicit activation steps.

Validation context

Shadow routing and a real documentation worker already worked. A one-task comparison of three requested model configurations also completed, and timings/token usage were recoverable from native records.

That pilot is not sufficient qualification evidence. The purpose of this request is to establish a supported evidence path before spending further calls on qualification studies.

If native records cannot provide the required guarantees, please identify the exact missing host fields or lifecycle guarantees and the smallest upstream change needed.