Skip to content

Capture resolved model/effort/sandbox in job records#506

Open
cubicj wants to merge 1 commit into
openai:mainfrom
cubicj:capture-resolved-settings
Open

Capture resolved model/effort/sandbox in job records#506
cubicj wants to merge 1 commit into
openai:mainfrom
cubicj:capture-resolved-settings

Conversation

@cubicj

@cubicj cubicj commented Jul 15, 2026

Copy link
Copy Markdown

Summary

Job records never capture the model, reasoning effort, or sandbox a job actually ran with (#481). Background task jobs persist the raw CLI request, but those fields are null when flags are omitted; foreground tasks and review jobs record nothing at all. The only place the resolved values exist today is the Codex rollout file, and joining a job record to its rollout fails in practice: date directories use local time while job timestamps are UTC, and rollout filenames carry a session id that does not match the job's threadId (both hit independently in the issue thread).

Change

The app-server already reports what it resolved: thread/start and thread/resume responses echo model, modelProvider, reasoningEffort, and the full sandbox policy with config.toml fallback applied, and the plugin currently discards everything but thread.id. This PR captures that echo instead of adding any new resolution logic, so it stays truthful regardless of how the pending override-mechanism discussions (#471, #408, #476, #482) land.

  • lib/codex.mjs: runAppServerTurn and runAppServerReview build resolved = { model, modelProvider, reasoningEffort, sandbox } from the thread response, attach it to the existing "Thread ready" progress event, and include it in the returned result. turn/start responses carry no effort field, so an explicit per-turn --effort is overlaid onto resolved only after the turn/start request is accepted — a rejected or failed turn never records a requested effort as if it had run.
  • lib/tracked-jobs.mjs: the job progress updater patches resolved into the job file and state index mid-run, the same way it already handles threadId, so failed and cancelled jobs still record what they ran with. The completion write adds resolved explicitly because it spreads the in-memory running record.
  • codex-companion.mjs: each execution object lifts result.resolved next to threadId/turnId; all job kinds share runTrackedJob, so foreground tasks, background workers, native review, and adversarial review are covered without per-path changes.

Job records gain one nested field, next to the existing raw request fields, so both layers stay visible — requested versus server-confirmed:

"resolved": {
  "model": "gpt-5.4",
  "modelProvider": "openai",
  "reasoningEffort": "medium",
  "sandbox": { "type": "readOnly", "access": { "type": "fullAccess" }, "networkAccess": false }
}

Human-readable output is unchanged: renderers read job fields selectively, the progress-event patch rides the same write the threadId update already performs, and no log line formats change. status --json and result --json gain the field additively.

Verification

  • npm test: 92/92 passing. New coverage asserts resolved in the persisted job JSON for native review, adversarial review, resumed tasks, and the detached background worker (checked mid-run, while still running); an explicit --effort overriding the thread echo on success; and a turn/start failure case with an explicit --effort proving the failed record keeps the thread echo rather than the never-applied request.
  • npm run build (typecheck via tsconfig.app-server.json): clean.
  • git diff --check against the base commit: clean.
  • The fake-codex fixture's thread/start/thread/resume responses now mirror the real app-server's resolved echo (shape confirmed against the generated ThreadStartResponse/ThreadResumeResponse types and a live JSON-RPC probe against codex-cli 0.144.1).

Related Issues

Fixes #481

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Job records never capture the resolved model/effort/sandbox a job ran with

1 participant