/** * codex adapter — launches/resumes the `codex` CLI and scans its rollout * store for resumable history. Codex has no hook system (see * core/collector/codex-tailer.ts for how its analytics eventSource works * instead); this file only covers process launch/resume/doctor/history. * * Verified against a locally installed `codex-cli 0.134.0`: `codex resume * [SESSION_ID] [PROMPT]` (positional UUID or thread name) via `codex resume * --help`; the generic `-c key=value` config-override mechanism via `codex * --help`; and, via real spawns with `--strict-config`, that both * `developer_instructions` and `model_instructions_file` are real, * recognized keys (an earlier version of this file used the latter and * flagged both as unconfirmed — see buildConfigArgs below for why the * adapter now uses `developer_instructions` instead: `model_instructions_file` * makes codex's own startup depend on re-reading a file we already have the * content of, and an unreadable path there kills the process instantly with * no trust prompt, no TUI — precisely the "session has no live pty" a user * sees with zero indication why). */ import type { DoctorCheck, HarnessAdapter, LaunchOpts, PastSessionRecord, SpawnSpec } from "../../shared/types.js"; export interface CodexAdapterOptions { /** Overridable for tests. */ binary?: string; /** Host-supplied interpreter/entry script for a managed CLI (e.g. Electron-as-Node). */ binaryArgs?: string[]; binaryEnv?: Record; /** Overridable for tests. Defaults to the real home directory. */ homeDir?: string; } export declare class CodexAdapter implements HarnessAdapter { readonly id: "codex"; readonly eventSource: "transcript-tail"; /** `buildConfigArgs` inlines `systemPromptFile`'s contents as * `developer_instructions`, on both launch and resume — same delivery as * claude-code's flag, so a rehydration brief rides the generated file here * too and neither adapter needs a rehydration-specific code path. */ readonly systemPromptDelivery: "launch-flag"; private readonly binary; private readonly binaryArgs; private readonly binaryEnv; private readonly homeDir; constructor(options?: CodexAdapterOptions); doctor(): Promise; launch(opts: LaunchOpts): SpawnSpec; resume(agentSessionId: string, opts: LaunchOpts): SpawnSpec; /** * See `HarnessAdapter.readyFallback` and `detectBlockingPrompt`. Codex's * rollout file — and therefore the SessionStart-equivalent event * `SessionManager` otherwise waits on — isn't written until the first turn * is submitted. Confirmed empirically against codex-cli 0.134.0: an idle, * fully-interactive session produces no rollout for as long as nothing is * submitted. SessionManager therefore publishes fallback readiness after a * non-blocking frame settles (or reaches its bounded liveness ceiling), * while retaining the same check at request time. */ readonly readyFallback: "immediate"; detectBlockingPrompt(scrollback: string): boolean; detectReadyPrompt(terminalOutput: string): boolean; /** * See `HarnessAdapter.canResume`. Reuses the same rollout walk + * `session_meta` read `listPastSessions` is built on, so "codex has this * conversation" means exactly one thing in both places: a rollout file * under `~/.codex/sessions` whose `session_meta` carries this id AND this * cwd. The cwd match matters — `codex resume ` run from another * directory is a different session's context, not this row. * * The never-prompted case documented on `detectBlockingPrompt` is why this * can be false for an id we hold: codex writes no rollout file at all until * the first turn is submitted, so a session the user opened and abandoned * leaves us a `SessionStart` id with nothing behind it. */ canResume(agentSessionId: string, cwd: string): Promise; listPastSessions(cwd: string): Promise; } export declare function createCodexAdapter(options?: CodexAdapterOptions): HarnessAdapter; //# sourceMappingURL=codex.d.ts.map