#!/usr/bin/env node
/** Whether an ensureDaemon() error is the "managed codex build missing" case. */
export declare function isManagedCodexMissing(err: unknown): boolean;
/**
 * Should this invocation get the app-server (real-time wake) rail?
 *
 * `cogent-codex` is a full encapsulation of `codex`: ANY codex command works through it.
 * Only an interactive TUI session benefits from the daemon, so:
 *   - `cogent-codex` / `cogent-codex "prompt"` / `cogent-codex resume <id> …` → rail ON
 *   - `cogent-codex exec …` / `login` / `plugin add …` / `--help` → passed through as-is,
 *     and we do NOT even start the daemon.
 * Everything after a `--` separator is the user's payload, never a subcommand.
 */
export declare function wantsDaemonRail(passthrough: string[]): boolean;
/**
 * Build the `codex --remote` argv, pinning the working root to THIS launch directory.
 *
 * WHY (critical): the app-server daemon is a shared, machine-wide singleton rooted at
 * whatever directory it FIRST started in. A plain `codex --remote` TUI inherits the
 * DAEMON's cwd — so launching cogent-codex from project B, while the daemon started in
 * project A, would run codex against project A's files (wrong, and unsafe). codex's
 * global `-C, --cd <DIR>` sets the working root per-session (verified: `--remote -C /x`
 * roots the conversation at /x regardless of the daemon's cwd), so we pin it to the
 * caller's cwd. A user-supplied `-C`/`--cd` always wins (we don't add ours).
 */
export declare function buildRemoteArgs(sock: string, passthrough: string[], cwd: string): string[];
//# sourceMappingURL=cogent-codex.d.ts.map