/**
 * The directory of the Node binary Claudexor ITSELF is running on, when that
 * binary is safe to expose to a harness's inner login shell. In production this
 * is the notarized app-bundled runtime
 * (`.../Claudexor.app/Contents/Resources`); a CLI/dev daemon runs on the
 * managed `~/.claudexor/node/bin/node`. Putting this dir FIRST on the harness
 * PATH is the QA-022 fix: a vendor tool's inner `/bin/bash -lc` grandchild
 * re-sources login profiles (`path_helper`, `brew shellenv`) and would
 * otherwise resolve an ad-hoc Homebrew Node that macOS's code-signing monitor
 * SIGKILLs (`Killed: 9`). Anchoring the SAME Node the daemon already proved
 * runnable — by executing on it — lets the grandchild resolve a working Node
 * even after the login shell reshuffles PATH.
 *
 * Guarded so the prepend can never make things worse:
 *  - the path must be absolute and a spawnable regular file (the running
 *    process is itself proof the bytes launch — "self-contained/valid");
 *  - it must NOT itself be an at-risk Homebrew Node — prepending a killable
 *    Node's dir would poison the very shell we are trying to protect;
 *  - the REAL binary's dir (symlinks followed) is what we anchor — a symlinked
 *    launcher must not put the WRONG dir first on the harness PATH;
 *  - that dir must NOT be group/world-writable — prepending a dir any non-owner
 *    can write to lets a local attacker drop a malicious `node`/`bash` that then
 *    SHADOWS the system tools for every harness child.
 * Returns null when any guard fails; the guessed `preferred` entries still apply.
 */
export declare function managedRunnerNodeDir(execPath?: string, platform?: NodeJS.Platform): string | null;
/**
 * The managed toolchain root under `home`: the notarized Node distribution
 * Claudexor installs plus the pinned vendor CLI shims (`<home>/.claudexor/node`
 * — `bin/codex`, `bin/claude`, the `node` that runs them, and their
 * `lib/node_modules` payloads). ONE spelling shared by every harness PATH
 * producer.
 * Deliberately HOME-anchored, not config-dir-anchored — a
 * `CLAUDEXOR_CONFIG_DIR` override relocates the runtime root, never the
 * installed toolchain.
 */
export declare function managedNodeRoot(home: string): string;
/**
 * Single producer for the PATH every local harness discovery/run surface should
 * use. Surfaces may still inherit other env vars, but binary resolution must not
 * depend on whether the daemon was launched from a GUI app, login shell, or CLI.
 * Existing inherited entries are never dropped (only de-duplicated); the only
 * additions are the trusted `preferred` prefixes.
 */
export declare function normalizedHarnessPath(source?: NodeJS.ProcessEnv, execPath?: string, platform?: NodeJS.Platform): string;
export declare function harnessRuntimeEnv(source?: NodeJS.ProcessEnv, execPath?: string, platform?: NodeJS.Platform): NodeJS.ProcessEnv;
/**
 * Resolve which binary a harness child will ACTUALLY execute, using the same
 * normalized PATH the spawn layer composes. Doctor discloses this path so a
 * stale pinned shim (e.g. `~/.claudexor/node/bin/codex` shadowing a newer
 * install) is visible instead of silently answering for the wrong version.
 * Returns null when the binary is not on the harness PATH.
 *
 * `execPath`/`platform` are forwarded to `normalizedHarnessPath` (same defaults,
 * so production behavior is unchanged). Forwarding them is what lets a test
 * fully control the resolution PATH: without it the resolver always anchors the
 * REAL `process.execPath` dir (e.g. `~/.claudexor/node/bin`) first, and any
 * `claude`/`codex` living beside the running Node shadows an injected fixture —
 * the machine-specific parity failure this seam closes.
 */
export declare function resolveHarnessBinary(bin: string, source?: NodeJS.ProcessEnv, execPath?: string, platform?: NodeJS.Platform): string | null;
/**
 * Advisory explaining WHY a harness binary failed to resolve when the
 * filesystem still holds evidence of an install. The live incident this
 * guards: Homebrew's codex cask stayed registered (Caskroom dir present,
 * version pinned) while its payload and bin link had vanished, so every
 * surface dead-ended at "not found on PATH"/ENOENT with no path to repair.
 * Two evidence classes, checked in order:
 *
 *  1. an entry named like the binary exists on the harness PATH (or at the
 *     configured absolute override) but is not spawnable — dangling symlink,
 *     exec bit stripped, or a directory shadowing the name;
 *  2. nothing is on PATH at all, but a Homebrew Caskroom/Cellar dir still
 *     lists the binary as installed.
 *
 * Diagnostic only (doctor/discover append it); never gates a run and never
 * executes a package manager. Returns null when the binary resolves or when
 * there is nothing better to say than "not installed".
 */
export declare function brokenInstallAdvisory(bin: string, source?: NodeJS.ProcessEnv, brewPrefixes?: readonly string[]): string | null;
/**
 * Advisory when the Node binary running Claudexor is one macOS's code-signing
 * monitor is known to SIGKILL (Homebrew's adhoc-signed node). The daemon spawns
 * its harness children with this same execPath, so a GUI/launchd-launched daemon
 * on at-risk node can die mid-run. Returns null when not applicable. Diagnostic
 * only (doctor surfaces it); never gates a run.
 */
export declare function atRiskNodeAdvisory(execPath?: string, platform?: NodeJS.Platform): string | null;
//# sourceMappingURL=runtime-env.d.ts.map