/**
 * Shared helpers for locating Codex session files on disk.
 *
 * Codex writes rollout files to `$CODEX_HOME/sessions/YYYY/MM/DD/
 * rollout-<ts>-<uuid>.jsonl` — date-partitioned, unlike Claude's flat
 * directory layout. These helpers find a session's rollout file by UUID.
 *
 * RULE 3.1 RATIONALE
 *   Criticality: high (driver of conversation-log reads, resume index, etc.)
 *   Frequency:   per-read (per-resume, per-conversation-replay)
 *   Stability:   semi-stable (Codex changes session layout occasionally)
 *   Fallback:    none — if the layout changes, callers get empty results
 *   Verdict:     deterministic FS walk + canary (canary at canary/codexSessionLayoutCanary.ts)
 */
export declare function codexHomeFromConfig(codexHome?: string): string;
/** Find a rollout JSONL file by Codex thread UUID. Returns null on miss. */
export declare function findRolloutFile(threadId: string, codexHome?: string): Promise<string | null>;
/**
 * Synchronous variant of {@link findRolloutFile}. Needed by callers that run on
 * a sync code path and cannot await — notably the resume-map `jsonlExists`
 * guards (ThreadResumeMap, TopicResumeMap), which previously checked only the
 * Claude flat layout and so returned false for EVERY codex session (the
 * codex-compat resume bug: every codex thread looked expired/missing). Returns
 * the rollout path or null. A missing `$CODEX_HOME/sessions` (e.g. a pure
 * Claude agent) returns null fast — `readdirSync` throws and is caught.
 */
export declare function findRolloutFileSync(threadId: string, codexHome?: string): string | null;
/**
 * Find the single newest codex rollout file SYNCHRONOUSLY → `{ path, size, mtime }`
 * (or null when none / not a codex tree). Used by the RateLimitSentinel's codex
 * recovery-verification, whose callers (`report()` is sync) need a sync read.
 *
 * Rationale: the OpenAI rate limit is ACCOUNT-WIDE, so "did the throttle clear?" ==
 * "is the codex account producing output again?" == "did the newest rollout grow?".
 * The sentinel compares this against the captured baseline size; the existing verify()
 * already handles the newest-file CHANGING between baseline and check (it only counts a
 * size INCREASE, and refreshes the baseline to the current newest each cycle).
 *
 * Perf-safe (same concern as listAllRollouts — a busy account has tens of thousands of
 * rollouts): walk YYYY/MM/DD newest-first, take the newest rollout BY FILENAME (the
 * embedded ISO-ish timestamp makes a lexicographic sort chronological — no stat needed)
 * in the newest non-empty day partition, and `statSync` ONLY that one file. The recovery
 * check runs rarely (only during an active codex throttle recovery), so a single stat is
 * ample. A long-running session with an older filename but a newer mtime is the only
 * miss, and the account-wide signal still catches its growth via whatever rollout IS
 * newest-by-filename in the same window.
 */
export declare function findNewestRolloutSync(codexHome?: string): {
    path: string;
    size: number;
    mtime: number;
} | null;
/**
 * List rollout files under $CODEX_HOME/sessions, newest first (by mtime).
 *
 * Codex partitions rollouts by date: `sessions/YYYY/MM/DD/rollout-<ts>-<uuid>.jsonl`.
 * A busy account accumulates tens of thousands of these (one real machine: 14k
 * files / 1.4 GB). The original implementation `stat`ed EVERY file before
 * slicing to `limit`; an interim fix narrowed that to the newest partitions but
 * still `stat`ed every file in them (~3.6k on the same machine) — fast in a
 * healthy process, but catastrophic when the server's event loop is CPU-starved
 * (each `await fs.stat` needs a loop turn), which is exactly when `GET
 * /codex/usage` timed out.
 *
 * This avoids the per-file `stat` storm entirely:
 *   1. Enumerate date-partition dirs newest-first; `readdir` (one syscall each,
 *      NO per-file stat) the newest partitions to collect candidate PATHS until
 *      we have >= `limit * STAT_OVERSCAN` of them AND have covered >=
 *      MIN_PARTITIONS_SCANNED non-empty partitions.
 *   2. Sort candidates DESCENDING by path — the zero-padded `YYYY/MM/DD` dir +
 *      `rollout-<ISO-ish-ts>` filename make a lexicographic sort chronological
 *      by CREATION time, no `stat` needed.
 *   3. `stat` ONLY the top `limit * STAT_OVERSCAN` candidates for the
 *      authoritative mtime, sort by mtime, return the newest `limit`.
 *
 * So a `limit`-8 call does ~32 `stat`s instead of ~3.6k. Trade-off: "newest by
 * mtime" becomes "newest by mtime among the newest-created candidates" — exact
 * for the rate-limit reader (account-wide windows are identical across any
 * recently-active session); the only miss for the resume/token-ledger callers is
 * a session whose creation is older than the newest `limit * STAT_OVERSCAN` yet
 * is still the single most-recently-touched file — vanishingly rare. A
 * non-date-partitioned layout falls back to the original full walk.
 */
export declare function listAllRollouts(codexHome?: string, limit?: number): Promise<ReadonlyArray<{
    path: string;
    mtime: number;
}>>;
//# sourceMappingURL=sessionPaths.d.ts.map