type BackendKind = 'keytar' | 'file';
/**
 * Is the OS-native keyring service STRUCTURALLY UNREACHABLE in THIS process?
 *
 * - macOS / Windows: the OS keychain (Keychain / Credential Manager) is always
 *   present, so this is always false.
 * - Linux: keytar/libsecret reaches the Secret Service over the D-Bus *session*
 *   bus, which it discovers via several mechanisms. On a truly headless box
 *   (Docker, CI, `ssh` without a GUI/forwarded bus) NONE of them resolve, so
 *   keytar's native addon LOADS but every operation throws ("Cannot autolaunch
 *   D-Bus without X11 $DISPLAY" / "no Secret Service"). We return true only when
 *   EVERY discovery signal is absent — being conservative so we never downgrade
 *   a machine where the keyring could actually work:
 *     1. a GUI display (`DISPLAY` / `WAYLAND_DISPLAY`) — D-Bus can X11/Wayland-
 *        autolaunch a session bus + keyring from these even with no bus env set;
 *     2. an explicit `DBUS_SESSION_BUS_ADDRESS`;
 *     3. the per-user bus socket — canonically `$XDG_RUNTIME_DIR/bus`, usually
 *        `/run/user/<uid>/bus` under systemd; we check both.
 *
 * IMPORTANT (Stage 2 Codex): this returning true means "no OS keyring is
 * REACHABLE in this process", NOT "no keytar identity has ever existed on this
 * machine". The same machine could have a keytar identity from a prior desktop
 * session (e.g. GUI login, then SSH in with no forwarded bus). Auto-selecting
 * the file backend in that case would fork the device identity — so the caller
 * gates the auto-fallback on a "keytar was used here" marker (see
 * `autoFileOrRefuse`), refusing to silently downgrade a machine that has a real
 * keyring identity. A transiently-locked desktop keyring still has a bus/display,
 * so it never reaches the fallback at all.
 */
export declare function osKeyringStructurallyAbsent(): boolean;
/**
 * Do durable file-backend credentials already exist on this machine? True when
 * ~/.codevibe holds any `<service>.json` credential file (written by a prior
 * file-backend session — a headless auto-fallback OR an explicit opt-in run).
 * The marker dotfiles (`.keyring-used`) are excluded by the `.json` test, and
 * `<service>.json` is the ONLY `.json` we ever write into ~/.codevibe
 * (writeFileStore → fileStorePath).
 *
 * This is the signal that closes the REVERSE fork: a machine that fell back to
 * file storage and wrote its device identity there, now running in a session
 * where the OS keyring is available again. Selecting keytar at that point would
 * read an EMPTY keyring and mint a brand-new device identity — orphaning the
 * existing file identity and breaking the user's E2E sessions. So when durable
 * file creds exist we keep using the file backend instead of switching to keytar.
 * Checked on every platform (the opt-in path can create file creds anywhere) and
 * checked in initBackends right AFTER the explicit `CODEVIBE_ALLOW_FILE_KEYCHAIN=1`
 * opt-in (which always routes to file) but BEFORE the keytar probe, so the no-fork
 * guarantee holds whether or not keytar loads in this session.
 *
 * Exported for direct unit testing — the keytar load itself goes through an
 * `eval('require')` that escapes the test mock registry, so the predicate is
 * pinned down here rather than only through a (non-deterministic) init path.
 */
export declare function fileStoreHasCredentials(): boolean;
/** True if the file backend was auto-selected (no OS keyring service present). */
export declare function wasAutoFileFallback(): boolean;
/** The active backend kind, or null if not yet initialized. For tests / diagnostics. */
export declare function getActiveBackendKind(): BackendKind | null;
export declare function getPassword(service: string, account: string): Promise<string | null>;
export declare function setPassword(service: string, account: string, password: string): Promise<void>;
export declare function deletePassword(service: string, account: string): Promise<boolean>;
export {};