Report connector state: session, gateway, entered target (probe-verified), permission mode, the ops-console URL and token expiry, and whether the connection settings are complete. Never returns credentials. Strictly read-only — to invalidate the console token use jumpserver_console_rotate_token.

Revoke the ops-console access token and issue a fresh one. In stable mode (the default) the console address is unchanged — reload the page and it picks the new token up. Use when the console reports 令牌已过期. Side-effecting (the old token dies immediately), so not read-only.

Open the persistent JumpServer SSH session and wait until the menu is detected. Idempotent — if a session already exists this does NOT create a second one, it returns the current state. One session per conversation.

Enter a target asset THROUGH the JumpServer menu by its IP or name. Requires the session to be at the menu. A probe (hostname/whoami/pwd) runs internally and the asset is reported as entered only after it verifies. When the target has multiple authorised bastion users, KoKo shows a numbered list ending in ID>; pass accountIndex (the displayed ID, usually 1 or 2) to pick one, or omit to fail with ACCOUNT_SELECTION_REQUIRED and the parsed list in detail. An asset the bastion cannot reach (网络不通（连接超时）) fails fast as ASSET_UNREACHABLE and is then refused for 2 minutes — report it to the user instead of retrying.

List the assets this account is authorized for WITHOUT entering any of them: KoKo menu command "p" (display-only), parsed locally, cached ~5 min. Filter by substring or by a configured asset group. Call this before jumpserver_run/jumpserver_batch — never guess IPs, and never type an asset name into the menu (KoKo auto-logs-in on a unique hit).

Run ONE simple command on the CURRENTLY entered asset and return stdout plus the real exit code (completion is detected by a unique marker, never by waiting a fixed time). Send one simple read-only command — no for/if loops, no $(...) substitution, no multi-statement one-liners, because READ_ONLY classifies every command statically and blocks shell structure. For several checks on one target use jumpserver_batch.

Run ONE simple command on a target reachable through JumpServer: connects (or reuses the session), switches asset when necessary, verifies the target, executes, and returns structured output. Same command-style limits as jumpserver_exec. For MULTIPLE metrics on one target call jumpserver_batch ONCE instead of calling this repeatedly.

Run simple commands across one or more targets in a single call. All commands of a target run before the next target is entered (target affinity). Put ONE simple read-only command per commands[] entry — no for/while loops, if branches, $(...) substitution or chained redirection; each entry is classified independently and statically.

Leave the currently entered asset and return to the JumpServer menu. Sends exit at most once, and reports success only after the menu is detected again.

Close the JumpServer session: PTY, SSH channel, buffers and timers are released and the connector returns to the DISCONNECTED state.

Read-only terminal mirror: the recent PTY event stream (output chunks, state transitions, target changes) plus the current state. Poll incrementally with sinceSeq. Use it to show the user what the terminal looks like now, or to diagnose a stuck menu. Credentials are redacted by the observer.

Read the local audit trail of THIS connector in-chat: recent audited events (time, operation, target asset, redacted command, risk, result). Use it when the user asks what the AI ran through JumpServer. Purely local file read — never touches the bastion, and works with no session and no configuration.

Collect a STRUCTURED host inventory from one or more servers using FIXED read-only probes (the connector decides the commands — do not invent shell). Returns parsed facts (OS, kernel, uptime, load, memory, disks, IPs, listening ports, connections, processes, services, nginx upstreams, java, docker, roles) instead of raw shell text. Use this rather than a pile of jumpserver_exec calls. Profiles: basic / network / process / service / web / java / database / container / full.

Build the relationship graph between servers: which host proxies or connects to which, on which port, with what evidence (nginx upstream, ESTABLISHED socket, /etc/hosts). Internally runs the read-only inspect probes and returns nodes (roles, ports, OS, load, memory) plus edges (type, port, confidence, evidence). Use it for "what is the relationship between these hosts" instead of guessing from names. depth>=2 also links app nodes sharing one upstream.

Run a NAMED runbook (a reviewed, reusable recipe from config "runbooks") across one or more servers: the SAME steps run on every host, and the results come back grouped per target and per step. Each step is an inspect profile or an explicit READ command; a non-READ step is SKIPPED and reported, never executed. Steps carrying expect assertions yield a PASS/FAIL verdict per step, per target and overall.

Run the SAME read-only command or inspect profile across several servers and report what DIFFERS — which host has a different config, a missing listener, a full disk. Returns groups of identical hosts plus, for each outlier, the lines it is missing or has extra versus the majority. Use it for "are these nodes configured the same?" instead of eyeballing raw dumps. Only READ is accepted; a mutating command refuses the whole call.

Capture a NAMED baseline snapshot of one or more servers: the read-only inspect probes run and a compact state (OS, kernel, cores, memory, disks, listening ports, services, roles) is SAVED to data/baselines/.json. Pair it with jumpserver_baseline_compare before and after a change window to prove what actually changed. Writes a file, so this is NOT a read-only operation.

Compare a saved baseline (jumpserver_baseline_capture) against the CURRENT state of the same servers and report DRIFT: which hosts changed and exactly what changed (added/removed listening ports, disk usage, services, roles, kernel, cores, memory %, load). Use it after a change window, or periodically, to prove what moved. Hosts that cannot be reached now are reported as unreachable, never as unchanged.

Send Ctrl+C to the remote shell NOW to interrupt whatever is running (a stuck command, a tail that will not end, a long find). Out-of-band: it does NOT wait for the current operation to finish. Afterwards the connector re-probes the shell and reports whether it is usable again (ASSET_SHELL) or collapsed to UNKNOWN. Use it instead of jumpserver_close when you only want to stop the remote job and keep the session.

Start a STREAMING job on a server — for commands that never return on their own: tail -f /…/stdout.log, journalctl -f -u nginx, tcpdump, top -b, ping. Returns a jobId; then poll jumpserver_job_read(jobId) for the new output and call jumpserver_job_stop(jobId) when done. While a job runs the shell is reserved for it (other commands get SESSION_BUSY), and it auto-stops at maxDuration.

Read the output of a streaming job (jumpserver_job_start) as a CURSOR READ: by default it returns only what arrived after the previous read, plus nextSeq to pass back as sinceSeq so you resume exactly where you left off (safe to retry, never re-consumes old lines). full:true returns the whole buffered output instead.

Stop a streaming job: sends Ctrl+C to the remote shell and releases it for normal commands.

List streaming jobs of this conversation (id, target, command, state, elapsed, buffered bytes).