/**
 * MojoCliAdapter — minimal pass-through adapter for mojo-backed sessions.
 *
 * mojo (@byted/mojo) is NOT driven as an interactive TUI here, and that is a
 * deliberate, empirically forced choice:
 *
 *   1. `--yolo` / `-r` / `-c` / `--output-format` / `--timeout` / `--idle-timeout`
 *      are all documented AND observed as "仅 -p" (print/headless mode only).
 *      Passing them without `-p` does not start a TUI — the process just waits
 *      on stdin until EOF. So there is no way to inject them into a long-lived
 *      interactive process the way the kimi/grok adapters do.
 *   2. mojo keeps NO local per-session transcript. `~/.mojo` holds only
 *      credentials/ memory/ skills/ — session state lives server-side. So the
 *      grok-style "tail updates.jsonl to detect turn end" bridge is impossible,
 *      leaving only screen-scraping, which is unreliable under long output.
 *
 * Instead mojo exposes a clean headless control plane
 * (`-p --background` + `mojo session get|respond|confirm|cancel`, all emitting
 * one uniform single-line JSON envelope), which maps almost 1:1 onto the
 * riff-style API-backed backend. All real work therefore happens in
 * MojoBackend, which translates write() into mojo CLI invocations.
 *
 * Empirically verified against @byted/mojo 1.0.10 (linux-x64).
 */
import type { CliAdapter } from './types.js';
export declare function createMojoAdapter(_pathOverride?: string): CliAdapter;
export declare const create: typeof createMojoAdapter;
//# sourceMappingURL=mojo.d.ts.map