CLI Reference

Reference for the gori command line. Running gori with no subcommand starts the TUI.

gori [command] [options]

Global flags: -v / -V / --version, -h / --help, and --config PATH (a settings file for one run; see --config PATH below).

gori tui

Start the intercepting proxy and TUI. This is the default when no subcommand is given.

gori
gori tui --listen 0.0.0.0 --port 8080

GORI_HOME is an environment variable, not a flag. Project selection in the TUI is done through the project picker. Bind flags only set the global layer for this run. See Configuration. For the root CA path, use gori ca.

gori run

The non-interactive suite. Each subcommand operates over a project. With neither --project nor --db it uses, in order: the project GORI_PROJECT names, the one pinned with project switch, or the most-recently-active project. It says which once on stderr (gori run: using project demo (from GORI_PROJECT)), because the last of the three moves whenever another project is written to. A GORI_PROJECT or pin that names no project is refused, never skipped. --project and --db are alternatives: passing both is a usage error, not a silent win for --db. See the Scripting guide for the working patterns.

gori run <subcommand> [verb] [options]

Common flags across read subcommands: --project=NAME, --db=PATH, --format=FMT (usually text or json), and --json, which is --format=json on every command whose --format offers it. An unknown option or subcommand prints one line naming the nearest real one (did you mean --format?) and where --help is, on stderr. Global flags go after the verb: gori run rewriter rm 1 --project=x, not gori run rewriter --project=x rm 1, which is rejected as a usage error rather than silently listing.

Read subcommands open the store read-only and never take the capture lock, so they are safe to run against a project a live TUI is capturing into. A body: query drains the search index and is therefore a write. A --db file that is not a gori project (another tool's SQLite database, or an empty file) is refused before anything touches it; commands that create their database (import --db, capture --db) still initialise an empty file, but refuse one that holds another tool's tables.

Write subcommands share that project's WAL database with the TUI and MCP. They serialize through the Store writer and can run while the TUI is open, but a capture commit can temporarily own the SQLite writer slot. A short-lived subcommand gives its SQLite open/writer waits a one-second budget; if the slot is still busy, the required write exits non-zero and says the project is locked by another gori, with the workaround (retry, or read it with a read-only subcommand). A subcommand that keeps the project open for a whole run (discover, fuzz, import, mine with a --macro, probe, retest run, oast listen/resume, intercept, sitemap js --scan) keeps the standard five-second wait instead. A repeater send also fails instead of claiming success when its network response could not be saved, so a script can distinguish a completed write from a response that needs attention.

Output contract

STDOUT carries data; warnings, counts, and export confirmations go to STDERR, so a pipe stays clean. A reader that closes the pipe early (… | head) exits 0 quietly.

Captured text in text output shows control and invisible characters by name (⟨ESC⟩, ⟨NBSP⟩, ⟨ZWSP⟩, ⟨RLO⟩), whether or not STDOUT is a terminal, so an escape sequence in a request cannot drive your terminal and a hidden character is visible. The show and repeater text views keep their line breaks, CRLF included. --format json carries those characters as they are, replacing only invalid UTF-8, and --format raw is the exact bytes.

--format json is one JSON document and --format jsonl is one object per line, on every command:

Without --fail-if-no-matches, a fuzz run that matched nothing and errored on every send still exits 1, so "no findings" stays distinguishable from "never reached the target". With the flag, 3 wins. A run whose stop condition was met is exempt from both rules: a send that timed out can meet --stop-on 'time:>=5000' while it stays an unmatched error row, and that is the result the run was looking for.

A create takes --format json and answers with the new row. repeater create, issues create, notes create, views add, colormarker add, rewriter add, rewriter extract add, probe rules add, oast providers add, links add, project scope add and project host-override add print one object on STDOUT, read back after the write committed, in exactly the shape that family's listing prints for the same row. A script therefore takes the id with jq .id instead of scraping it out of a sentence. The id is whatever the rest of that family takes: a number for most, the rule name (custom_p_7) for a probe rule and the provider key (p_3) for an OAST provider. A view is addressed by name, so its object carries name and key rather than an id. notes create adds index, the position the text line names, and links add adds created, which is false for a pair that was already linked (with that link's id). Text output is unchanged.

issue=$(gori run issues create --title "IDOR on /v1/users/{id}" --severity high --format json | jq .id)
gori run links add --owner=issue --id="$issue" --ref=flow --ref-id=42 --format json

run capture

gori run capture --port 8070 --format json --for 5m

run shell

Open a terminal whose tools go through a live gori and trust its CA, without touching OS settings. It is the terminal counterpart of the palette's Open browser.

gori run shell                            # interactive $SHELL; `exit` to leave
gori run shell -- curl https://target/    # one command, exits with its status
eval "$(gori run shell --print)"          # export lines for the shell you are already in
gori run shell --print --shell fish | source

The address comes from the gori capturing the project (its live port, even after a port fallback), and the CA from the one that gori signs with. When nothing is capturing the project, the command refuses unless --proxy names an address. When capture is paused, it warns and continues.

What gets set: http_proxy, https_proxy, HTTP_PROXY and HTTPS_PROXY point at gori, and NO_PROXY/no_proxy are unset so local targets are captured too. SSL_CERT_FILE, CURL_CA_BUNDLE, REQUESTS_CA_BUNDLE, GIT_SSL_CAINFO, AWS_CA_BUNDLE, PIP_CERT, CARGO_HTTP_CAINFO, DENO_CERT and NIX_SSL_CERT_FILE point at a bundle under ~/.gori/shell/. That bundle holds the store the terminal already trusted (your own SSL_CERT_FILE, else the system roots) plus gori's root, because most of these variables replace a tool's trust store rather than add to it. A CA variable you had set for one tool (say REQUESTS_CA_BUNDLE) gets its own file with gori's root added, rather than the shared one. NODE_EXTRA_CA_CERTS adds gori's root, NODE_USE_ENV_PROXY=1 turns on Node's proxy support, and GODEBUG=x509sslcertoverrideplatform=1 makes Go on macOS read SSL_CERT_FILE. GORI_SHELL=1 and GORI_PROXY=HOST:PORT mark the shell for your prompt:

# ~/.zshrc or ~/.bashrc
[ -n "$GORI_SHELL" ] && PS1="(gori) $PS1"

Whatever the shell replaces or unsets is recorded as GORI_SHELL_ORIG_<NAME> (for example GORI_SHELL_ORIG_HTTPS_PROXY). A gori started inside the shell (gori run send, a second capture) does not use the shell's proxy variables as its own upstream, so its traffic is not captured twice. It uses the recorded proxy and NO_PROXY instead, and an upstream you configure explicitly still applies. A shell started inside a gori shell also starts from the recorded values, so it does not keep trusting the outer gori's CA.

Not covered: Go programs built with a toolchain older than 1.27 on macOS verify through the keychain; Go never proxies localhost or loopback addresses; Node uses the proxy only in releases that support NODE_USE_ENV_PROXY (stable in v22.21 and v24.10); Java needs a truststore via JAVA_TOOL_OPTIONS; tools that pin their own trust store are not covered.

run browser

Open a browser that goes through a live gori and trusts only its CA: the palette's Open browser, from a script. It reuses the same profile under ~/.gori/browser/<id>, stays in the foreground until the browser exits, and closes the browser on Ctrl-C.

gori run browser                                   # the first detected browser
gori run browser --browser brave
gori run browser --remote-debugging-port 9222      # for a browser-automation MCP server

It finds the proxy the way run shell does, and refuses in the same words when nothing is capturing the project.

With --remote-debugging-port, the command prints the endpoint the browser reports (http://127.0.0.1:N). Point a browser-automation MCP server at it, and the pages it drives are captured in gori:

npx @playwright/mcp@latest --cdp-endpoint http://127.0.0.1:9222
npx chrome-devtools-mcp@latest --browserUrl http://127.0.0.1:9222

If that profile is already open in a running browser, the launch is refused, since the running browser takes it as a new window and opens no port.

run android

Point an Android emulator or rooted test device at a live gori over adb: the palette's Set up Android device, from a script. gori keeps its loopback bind; adb reverse maps the device's 127.0.0.1:PORT to it, and the device's global HTTP proxy is set to that address.

gori run android devices                 # serial, state, model, api=N,emulator,root (adbd as root; listing never asks su)
gori run android setup --dry-run         # print the adb commands, change nothing
gori run android setup --system          # trust the CA in the system store, as root
gori run android undo

setup finds the gori the way run shell does. --user (the default) pushes the CA to /sdcard/Download/gori-ca.crt and opens Security settings; install it there as a CA certificate. Apps targeting API 24+ trust a user CA only if their network security config opts in. --system mounts a tmpfs over /system/etc/security/cacerts holding the existing certificates plus gori's root as <subject_hash_old>.0. It runs as root (adbd as root, or su), shows every command first under --dry-run, and is gone when the device reboots. Without root it is refused rather than downgraded to --user, and Android 14+ (API 34), which reads system CAs from the Conscrypt APEX, is refused for now.

undo sets http_proxy to :0, removes the reverse mapping (the port is read back from the device's proxy, or --device-port), deletes the pushed file and, with root, unmounts the tmpfs. It is safe to run twice. A user CA you installed stays in Settings until you remove it.

Not covered: certificate pinning, and traffic that ignores the global proxy.

run history / ls

gori run history -q 'status:5xx' --limit 100 --format json

Subcommands: history show <id> (same as run show), history delete <id>… (one id or several, in one transaction; an unknown id refuses the whole call), history delete -q QL --yes, history clear --yes.

This project's History columns are drawn by default, so a headless listing shows what the TUI's History tab shows; --no-columns is the way back to the plain listing. In text they print as label=value after the row (every column, empty ones included; "the descriptor found nothing here" is an answer worth seeing); in json they arrive as a columns object, absent when no column is defined. A = separates the label only when it comes before the first :, so regex:token=(\w+) is the pattern and not a column named regex:token. Each column costs one extra read per printed row, and up to 512 KiB of body for the three body-scoped kinds.

Each json/jsonl row carries the flow's absolute url and a compact headers object for the request (a repeated header name becomes an array). Bodies are not inlined; that is run show.

Sensitive header values are [REDACTED] in that object by default, and the row is marked sensitive_headers_redacted: true when anything was withheld. A listing is an inventory, and one run to answer "what did I capture?" should not put a live session cookie in a terminal log or an agent transcript. --include-sensitive returns the exact bytes. Names, wire order and the repeat count survive either way, so the redacted row still says what the request was. An obs-fold continuation is folded into the field it continues and redacted with it, rather than appearing as a header of its own.

The same redaction covers a header: column whose selector names a sensitive header, and every cookie: column, since a named cookie's value is part of the Cookie header the row is already withholding. What it does not cover, and cannot: regex:, jsonpath: and position: columns, which can lift a credential out of any byte of the message with nothing in the descriptor to say whether they do; a credential in the query string, which is part of url and target; and the text listing, which is the interactive read rather than the feed a script captures. --format har also carries the captured message in full, by design: an interchange document has to be replayable.

Every row also carries source, where the flow came from (proxy, repeater, fuzzer, discover, import, …; null on a flow captured before gori recorded provenance), plus source_surface (tui / cli / mcp) and source_ref when there is one. The text format prints a [repeater]-style chip on anything that is not ordinary captured traffic. Filter on it with src:; the same keys are on MCP list_history and get_flow.

history delete -q QL deletes every flow the query matches and needs --yes; without it, it prints how many would go and refuses. A query naming a field QL does not know (methd:) is refused too, rather than silently matching nothing. With neither an id nor -q it refuses; wiping the project is history clear --yes.

--format har writes the whole result set as one HAR 1.2 log on STDOUT, oldest entry first, so a query can be handed to a teammate or loaded into Burp, Charles, or a browser's network panel. See HAR export.

run show

gori run show <flow-id> --format raw

--headers-only and --max-body=BYTES make the text and json views compact: --headers-only replaces each body with a line naming its size ([body omitted by --headers-only: 149504 bytes]; in JSON the body object keeps encoding and size and gains omitted: true), and --max-body prints the first BYTES of each decoded body followed by [… truncated by --max-body: showing 2048 of 149504 bytes] (in JSON text/base64 hold the prefix, size the total, shown_size the prefix, and truncated is true). Either one also leaves out the sections derived from the bodies: decoded views, gRPC messages, WebSocket frames and SSE events. A transcript is still named with its count (=== SSE EVENTS (40) — not printed under --max-body ===, or {"count": 40, "omitted": true}). They are refused with the other formats, each of which writes the whole message, and with each other.

--ws-match=QUERY prints only the WebSocket messages that match, in every format that carries the transcript: ws:needle (case-insensitive), ws~regex, or a bare needle, matched exactly as the ws: query term matches. A line on STDERR names how many of the socket's messages were kept.

--original prints a flow as it was before a Match & Replace rule or an Intercept edit changed it: the client's request and the origin's response, in any --format, with a side nothing changed shown as stored. A flow nothing changed is refused.

--format is text, json, raw (exact bytes), har (a one-entry HAR log), or one of the request-as-code serializers: curl, python (requests), fetch (JavaScript), go (net/http), httpie, and csrf (a self-submitting HTML CSRF PoC). Each emits byte-identical text to the TUI's Space → Y Copy as… row of the same name. --request-only / --response-only limit the output and do not apply to har; every request-as-code format is the request, so --response-only is refused for all of them. Two caveats go to STDERR rather than into the snippet on STDOUT: a request body cut at the capture cap is carried short, and a WebSocket flow serializes as the upgrade handshake with none of its frames. Decoded SAML/JWT/GraphQL/params, WebSocket messages, and SSE events are included where present.

Safe evidence export

--redact [PROFILE] writes the sanitized derivative of the flow instead of the captured bytes: values a redaction profile names are replaced by a keyed placeholder, [REDACTED:3f1c9ab4]. Equal values get equal tags, so a reader can still see that the token in the request is the token in the response without seeing either. The tag is an HMAC under a secret minted once per install, not a digest of the value. A truncated hash of a 4-digit PIN or a wordlist password is recovered in milliseconds, which would make the placeholder itself the disclosure.

It applies to every --format, because the flow is sanitized once before anything renders it: raw, text, json, har, and all six request-as-code serializers. --no-redact writes the captured bytes even when redaction is this project's or this install's default; --redact-preview lists what would go (side, JSON Pointer or form key, the rule that fired, the placeholder) and prints no document.

What it covers and what it does not:

• Bodies only. Heads, URLs and query strings are untouched, and the sentence on STDERR says so every time. A credential in a Cookie header or a ?token= query string is a different axis with its own consumers (the url in a HAR, curl's argument, the row's target) and is not part of a profile.
• The stored bytes never change. History, the Repeater, the Comparer and get_response_body_chunk keep reading the capture exactly. Sanitizing happens on the way out; replay after an export is byte-identical to replay before it.
• A JSON body is re-serialized, so a sanitized one carries gori's whitespace and key order rather than the origin's. When the exact framing is the evidence, use --no-redact.
• The head is repaired to describe the sanitized body: Content-Length is rewritten, and a body gori had to decompress or de-chunk to read loses its Content-Encoding / Transfer-Encoding (reported on STDERR).
• A body gori cannot read is withheld whole, not partially sanitized: anything that is not valid UTF-8, and any multipart/* (gori does not split its parts yet, so it cannot tell an uploaded file from a form field). The placeholder says how many bytes went and why.
• A body that does not parse falls back to a conservative text pass: the profile's own patterns, its field names re-expressed as "name": "value" / name=value text rules (truncation tolerated), and two built-in shapes that are unambiguous wherever they appear: a JWS/JWE compact serialization and a PEM PRIVATE KEY block.

Every caveat, and the count, go to STDERR. STDOUT stays the document, so gori run show 42 --format har --redact > evidence.har is still a pure HAR.

HAR export

A HAR gori writes imports back into gori as the same flow (gori run import --har), so it round-trips. Four things to know:

• Bodies are the wire bytes, de-chunked but not decompressed, base64-encoded when they are not valid UTF-8. The Content-Encoding header stays in headers, so body and head keep describing the same message.
• A body capped at the capture limit is marked, never emitted as if complete: bodySize and content.size stay the true wire size while the text carries only the captured prefix, and a comment on content/postData says so. The command also reports the count on STDERR.
• A WebSocket flow exports with its messages: the real 101 handshake, plus the captured transcript beside it in Chrome DevTools' _webSocketMessages field, and gori run import --har restores it. Direction, opcode (control frames included), bytes (base64 when not valid UTF-8) and millisecond timestamps survive; the per-frame shape (FIN/RSV/mask key) has no field in the format, so use --format json or raw when you need it.
• Flows with no captured response are skipped, along with a socket whose transcript is empty, since the handshake alone is not the exchange. The count and reason go to STDERR; STDOUT stays a pure HAR document.

run compare

Line diff of two flows, matching the Comparer tab.

gori run compare 41 42 --pane response --changes-only

Both sides' status · size · time and the A→B delta print above the diff, so a status flip or a size shift is visible before the first line is read. --format=json carries the same under meta, and a collapsed run becomes {"kind":"fold","hidden":N} rather than a gap.

--changes-only says what changed but erases where: a 400-line body with one edit comes back as two lines with no position. --context keeps the change in place and states how much it skipped.

run diff

The retest report: diff two projects at endpoint scale, where run compare diffs two messages. It answers the question half of an engagement is: what changed since last time?

gori run diff --from q1-audit --to q3-retest --format md

It sends nothing. This diffs captured traffic on both sides. Re-confirming that a finding still reproduces takes a request, and that stays a deliberate Repeater send.

Endpoint identity

Two engagements never capture the same identifiers, so a diff keyed on literal paths reports every row twice (once removed, once added) and says nothing. Endpoints are therefore keyed by the same folded template the Sitemap draws: /users/{uuid}, /items/{n}, /search (query variants folded onto their path). The fold runs over the union of both sides, so a route that met the fold threshold on one side alone still matches itself on the other.

The five verdicts

The removed/gone split is the point of the command. A thinner retest visits fewer endpoints, and collapsing those two into one bucket would report a short afternoon as a wave of fixes. Every output leads with that caveat, and the counts always cover all five verdicts even when --verdict narrows the listing.

changed is judged by a tolerance band (the same calibration repeater minimize and mine use) rather than byte equality, so a page whose length wanders between captures reads unchanged. Status is compared by class: a 200 that became a 201 is not a retest finding, a 200 that became a 403 is (and is reported on its own auth axis).

Issue retest

By default the report closes with each of the baseline's still-open issues and what became of the endpoint it was filed against: "still answers the same way, the finding likely still stands", "answers 404/410 now", "was not requested in the newer capture, retest it before closing". No request is sent; confirming a fix is your call.

Coverage and scope

Both sides' flow count, endpoint count, host count and capture window print above the counts, so a reader can see immediately when B's coverage is thinner than A's. When the two projects carry different scope rules the report says so, because an endpoint can be absent because that side's proxy was never recording it.

run intercept

Drive the live intercept queue of a TUI holding the capture lock. Interception is TUI-only: a headless gori run capture never holds a message, and every subcommand except list refuses when no capturing instance is publishing state (list says so on STDERR, or prints {"available": false, …} under --format json, and exits 0).

gori run intercept                              # held items + intercept state
gori run intercept get 3 --format json
gori run intercept forward 3
gori run intercept edit 3 --raw-file edited.txt
gori run intercept direction request
gori run intercept inject 42 --direction in --data '{"role":"admin"}'

list and get redact sensitive header values unless --include-sensitive is passed. Write subcommands round-trip through the project database and poll for the TUI's ack.

run repeater

Re-send one captured flow, or manage the Repeater workbench sessions shared with the TUI.

gori run repeater <flow-id> --target https://staging.example.com --http2 --diff

--headers-only and --max-body shape what is printed, never what is sent or stored: the body is replaced by [body omitted by --headers-only: 149504 bytes], or cut and followed by [… truncated by --max-body: showing 2048 of 149504 bytes], so a cut body never reads as a short one. The size is the decoded body's (de-chunked, decompressed), the one an uncut dump prints. In --format json the body object keeps size as the whole decoded size; --max-body holds the prefix in text/base64 and adds shown_size, with truncated: true, and --headers-only drops the bytes and adds omitted: true. The two flags are refused together. --headers-only --diff compares the two heads alone; --max-body is refused with --diff, whose comparison is of the whole messages. They take the same shape on repeater send, repeater h2, send and show.

repeater list: list saved Repeater sessions (--format text|json).

repeater create: create a Repeater session:

gori run repeater create --target https://api.example.com --request-file req.txt --name "login probe"
gori run repeater create --flow 42 --name "clone of 42"
generate-request | gori run repeater create --target https://api.example.com --request-stdin
pbpaste | gori run repeater create --curl - --name "from devtools"

The four request sources are mutually exclusive: naming two is refused rather than resolved by flag order. A request that arrives empty (an empty file, --request-raw '', or a pipe that produced nothing) is refused instead of creating a session that cannot be sent. --flow is not one of the four: it doubles as provenance, so it pairs with any one of them. --curl reads one curl command (see Repeater → Paste cURL) and supplies --target and --http2 from it unless you pass them.

--request-stdin reads a pipe or a redirect (--request-stdin < req.http), and refuses a terminal. A terminal echoes every byte back (the whole raw request, Cookie and Authorization with it) into the scrollback and into any captured PTY transcript, which is the exposure the flag exists to close for the process listing and the shell history. ^D also flushes the pending line rather than ending the read there, so a request with no trailing newline needs two of them and a PTY-driven harness that sends one waits forever.

The same rule covers every stdin road an operator names by flag: issues --notes-stdin, and the four that spell stdin - (sequence --tokens -, authorize --identities=-, rewriter --response-file=-, and - on any of the --…-file flags), plus a path that resolves to a terminal, such as --request-file /dev/stdin under a tty. A wordlist path is covered too: fuzz -w, mine --wordlist and discover --wordlist each refuse /dev/tty (and /dev/stdin under one) with wordlist is a terminal, not a file: … instead of blocking forever.

It does not cover the stdin sources gori falls back to when no flag was given (fuzz, mine, sequence, decoder, jwt, cookie, notes): there a terminal means "no source was given", and those commands print their own usage line instead. Those roads do now report an unreadable stdin (fd 0 closed by a cron or systemd unit) as a sentence rather than a backtrace, as the flag doors already did.

id=$(gori run repeater create -t https://api.example.com -f req.http --format json | jq .id)
gori run repeater send "$id"

repeater send <repeater-id>: execute a saved session, HTTP or WebSocket.

gori run repeater send 3 --diff
gori run repeater send 5 --message '{"op":"subscribe"}' --idle-ms 5000

--path sweeps one session's request across endpoints that differ only in path, without a session per path:

for n in $(seq 1 38); do
  gori run repeater send 1 --path "/api/v1/items/$n" --headers-only
done

It edits a copy of the stored request for this send (so do -H and -b): the session keeps its own request and its last response, because storing another target's answer beside it would show the TUI tab a response to a request it does not hold, and make the next --diff compare against the wrong endpoint. So response_saved is absent from --format json, a path field names the target that was sent, and the text status line ends with it (→ 200 in 218.4ms · /api/v1/items/42). --record-history still records the request as it went out, new path included, and --diff compares against the session's stored response.

A send that reached the origin exits 0 even when the writes after it fail, so a shell does not resend it. --format json says which: response_saved (present once a response was written to the session, false with response_save_error when the project refused the write or the session was deleted mid-send, in which case a later --diff would compare against the previous response) and, under --record-history, history_saved with history_error beside a recorded_flow_id that is then absent. Text mode prints the same sentence on STDERR.

repeater ws <repeater-id>: open a persistent HTTP/1.1 WebSocket session on a saved repeater (the gori run counterpart of the TUI's Live session and MCP's ws_session_open / ws_session_send / get_job / stop_job). Each line read from stdin is framed and sent as a TEXT message (or hex-decoded as a BINARY message under --binary), and every sent and received frame is printed to stdout as it arrives. EOF on stdin (without --for), --for=DURATION, or Ctrl-C sends a CLOSE frame and exits cleanly. On Windows a piped stdin blocks while reading, so server frames print when the next line arrives (a console stdin is fine).

printf '{"op":"ping"}\n' | gori run repeater ws 5 --engine-io --for 30s
gori run repeater ws 5 --for 30s --format json

repeater move <repeater-id>: reorder the workbench strip. --to N names the 1-based tab number repeater list prints; --up / --down step one place. Pass one of the three. Passing both --to and a direction is refused rather than resolved, and a --to outside 1-<count> is refused rather than clamped, so a session never lands somewhere the command did not name. --format json reports from_index / to_index / moved.

gori run repeater move 5 --to 1        # make it the first tab
gori run repeater move 5 --down

repeater delete <repeater-id> [<repeater-id>…] --yes: close one or more saved sessions and renumber the strip. --yes is required, and every id is checked before the first delete, so one unknown id refuses the whole call, so a typo cannot half-empty the workbench. Each line names the tab number the session had (read once, before anything shifts); --format json returns deleted (with was_tui_index), failed, and remaining. A session that could not be removed leaves a non-zero exit.

repeater race <repeater-id> <repeater-id> [<repeater-id>…]: fire several saved sessions as one synchronized race, so N distinct requests reach the server in one narrow window (a TOCTOU across different endpoints). Over HTTP/1.1 each request goes on its own connection and the last byte of every one is released together; over HTTP/2 they share one connection as a single-packet attack. Every session must resolve to one origin and share the transport, or the race is refused. --http2 / --http1 override the sessions' stored setting; --max-requests=N refuses a group larger than N rather than splitting it; --verbatim, --slot=NAME, --reframe-grpc, --tls-preset=NAME, -k, --timeout, --allow-unscoped and --format text|json behave as on repeater send. For many copies of one request, use fuzz --race=N.

gori run repeater race 3 4 --http2

repeater timing <idA> <idB>: differential timing analysis of exactly two saved sessions, for a difference too small to see in one send. The pair is sent --count=N times (1-500, default 30) after --warmup=N pairs that are thrown away (default 3; 0 measures from the first pair). Each pair is released together as in repeater race (HTTP/2 single-packet, HTTP/1.1 last-byte sync), or sent one after the other in alternating order with --interleaved. The verdict is read from the response order, not from one latency: how many pairs A arrived after B, under a two-sided sign test. It is a_slower or b_slower only below p = 0.01, no_difference otherwise, and inconclusive with fewer than 20 usable pairs (a pair where either side failed is dropped). Each variant's min, quartiles and max print beside it. Both sessions must share one origin and connection shape, and a pair that mixes HTTP/1.1 and HTTP/2 needs --http1 or --http2. --verbatim, --slot=NAME, --reframe-grpc, --tls-preset=NAME, -k, --timeout, --allow-unscoped and --format text|json behave as on repeater send, and the JSON is the object MCP timing_requests returns. A run with no usable pair exits 1.

gori run repeater timing 3 4 --count 100

repeater minimize <repeater-id>: shrink a request to the smallest form that still reproduces the response. --apply writes the result back into the session; --verbatim sends the stored bytes as-is (body params stop being candidates, because their framing could not be kept honest); --slot=NAME sends as that session slot; -k/--insecure, --allow-unscoped and --format behave as above.

repeater h2: send a field-native HTTP/2 request from an ordered HPACK field list, so duplicate or misordered pseudo-headers can be scripted.

gori run repeater h2 --target https://api.example.com --fields fields.json

--fields=FILE is a JSON file holding either a bare [[name, value], …] array or {"fields": [[name, value], …], "body": "…"} (body_base64 for binary). Nothing in the list is normalized: a leading colon, a leading-space value, an uppercase name are the payload. --target sets the dial origin, so the :authority and :scheme fields may deliberately disagree with it. -k/--insecure-upstream, --timeout=SEC, --sse-events/--sse-time, --allow-unscoped, --tls-preset=NAME, --headers-only, --max-body and --format text|json behave as on repeater send.

run send

Send one request and print the response: the headless form of MCP send_request{url}, built by the same code. It goes out through the project's upstream proxy, host overrides, scope and Sandbox like every other gori send, and leaves nothing behind unless you pass --record-history or --save-as-repeater.

gori run send https://api.example.com/v1/items/42 -H 'Accept: application/json' -b 'sid=abc'
gori run send --url https://api.example.com/v1/items -d '{"name":"x"}' -H 'Content-Type: application/json' --record-history
gori run send --url https://api.example.com --request-file req.http --headers-only

-X, -H, -d and -b mean what they mean to curl: -d is the body (and makes the request a POST with a form Content-Type unless -X or a -H says otherwise), -b is a cookie. Before #1383 -b was the body here, so a -b value with no = (an old -b '{"a":1}') is refused with a pointer to -d.

The exit status reports the exchange, not the HTTP verdict: a 404 or 500 exits 0 (ok: true in JSON), so check status. Exit 1 (ok: false) means there was no response, or gori could not frame or finish reading it.

A request that is a WebSocket handshake goes out as an ordinary request and its 101 is the answer, which the command says on STDERR. A framed exchange needs a session: repeater create, then repeater send.

--format json on send, repeater <flow-id> and repeater send carries MCP send_request's error contract beside the raw head: a failed send adds error_kind (connect, timeout, protocol, no_response, truncated_request, budget, busy, other), error_code, retryable and delivered, so a script tells a refused connection from a timeout without matching the error sentence; a response adds reason, http_version and the parsed headers ([{"name","value"}], in wire order, with value_lossy/value_base64 for a non-UTF-8 value). match_replace_applied: true says --apply-rules changed the request, and bounded (events or time) that an event stream was stopped at its --sse-events / --sse-time limit.

run fuzz

Sources: --flow=ID, --repeater=ID, --request=FILE, or stdin. Positions: §…§ markers, --auto, --mark=TOKEN, or --field=SPEC for a schema-known gRPC field.

Permanent fuzz runs

gori run fuzz … is ephemeral. Add the save verb before the same source/options to store every result permanently, with its complete rendered request, final wire request, response head, and response body:

gori run fuzz save 42 --auto --preset sqli
gori run fuzz save --request request.txt --target https://api.example.com --project acme --payloads a,b

A file/stdin save needs --project or --db; gori will not silently write a project-less sweep into whichever project happens to be most recent. --record-history remains independent: it controls History flows, not the saved result set.

run mine

gori run mine <flow-id> --locations query,headers --wordlist params.txt

Connections are reused by default, so a mine pays one TCP (and on https one TLS) handshake per worker rather than one per probe. The connections · N dialed · M reused line at the end of a run is where you see whether the target honoured it. Turn it off with --no-keep-alive when the target behaves per-connection.

run sequence

Grade the randomness of a token. Live: replay a request and extract the token from each response. Manual: analyze a pasted list with --tokens (no network). Alias seq.

gori run sequence 42 --cookie SESSIONID --count 500
gori run sequence --tokens tokens.txt          # '-' reads stdin

run authorize

Replay each selected flow under every identity (a header overlay standing in for an admin session, a low-privilege user, an anonymous client) and judge each response against the baseline's. An identity served what the baseline was served is a likely access-control bypass. The headless equivalent of the Authorize tab.

gori run authorize 12 13
gori run authorize --query 'host:acme.test method:GET' --identities identities.json

Identities come from the project (the TUI Authorize tab's list) unless --identities names a file:

[{"name": "anonymous", "remove": ["Cookie", "Authorization"]},
 {"name": "low-priv",  "set": [{"name": "Cookie", "value": "session=…"}]}]

set upserts headers, remove strips them, and the request as captured is the baseline unless an entry carries "baseline": true. At least one identity besides the baseline is required, or there is nothing to compare.

Flows that cannot be replayed meaningfully are listed on STDERR before anything is sent, each with its reason (no identity changes them, not a safe method to repeat, never completed, answered by gori, outside project scope, already queued). A selection where every flow was skipped is refused rather than run. If every send was refused before the socket, the run exits 1 and says so instead of reporting a clean result, because a run that sent nothing is not evidence that access control works.

run cache-deception

Check each selected flow for web cache deception: replay it as its captured (authenticated) identity to prime any cache, re-request the same url with no session, then make an anonymous request with a unique cache-busting query parameter as a control. Matching control content supports a public verdict (served) only when the control itself has no cache-hit signal. If the control is also a cache hit, the cache may have ignored the query and the verdict is review; matching anonymous content with a cache hit and different control content is a likely deception (cached). The check sends up to three requests per flow. Borrows the Authorize engine; the crafted paths that trigger it (;, .css, %00, dot-segments) are the Fuzzer's cache-delimiters payload set.

gori run cache-deception 12
gori run cache-deception --flow 12 --flow 13 --format json

Each flow reports one verdict: cached (the deception: anonymous served the authenticated response from a cache and the cache-busted control differed), served (no cache-hit evidence or a matching control without cache-hit evidence), review (similar but not identical, no decisive control, or a matching control that was itself a cache hit), protected (anonymous got a different response), blocked (gori refused the send), or errored. Each trial includes its own cache signal; the top-level cache is the anonymous response. Only safe methods (GET/HEAD/OPTIONS) are checked without --unsafe-methods. A flow gori cannot replay is reported on STDERR and the run moves on to the next one; the run exits 1 when no flow could be checked at all.

run session

The project's session slots: named identities, each a header overlay plus the extract rules whose bound values belong to it. This is the same list the TUI Authorize tab's identities card edits and MCP's *_session_slot tools manage: an Authorize run replays under every slot, and a send goes out as the one named by --slot.

gori run session                                     # list (values [REDACTED])
gori run session show admin --show-values
gori run session add --name admin --set 'Cookie: session=…' --rule SESSION
gori run session edit admin --clear-set --set 'Cookie: session=new'
gori run session baseline as-captured
gori run session rm admin
gori run session edit admin --refresh 12,14 --refresh-before jwt-exp
gori run session refresh admin

All verbs take --project=NAME / --db=PATH.

A --set value goes through the same header parser the TUI form uses: a name must be an RFC 7230 token and a value may not contain CR or LF, and a line that fails is refused by name rather than dropped.

from-flow builds a slot from a captured login. Point it at the flow that logged in and gori reads that flow's response into the overlay: every Set-Cookie name=value folded into one Cookie: header (attributes dropped, and a cookie the response deletes skipped), then the response's own Authorization, else a top-level access_token / token / id_token string in a JSON body as Authorization: Bearer <value>, else the request's own Authorization.

gori run session from-flow 4211 --name admin
gori run repeater 900 --slot admin        # re-send flow 900 as that identity

The overlay is literal: the bytes login handed back, saved with the project. It does not re-authenticate by itself, so a token that rotates (a short-lived JWT, a per-request CSRF value) belongs on the extract-rule path instead: gori run rewriter extract plus --bind-from FLOW, which re-mints the value once per run, refresh steps on the slot, or a Fuzzer or Miner request-time macro (--macro) for a value that changes on every request. The name is checked before the flow is read, so a duplicate is reported as a name clash rather than as "that flow is not a login".

from-request copies named headers from a captured request. This is useful when the credential or CSRF material is already on the request, or when you need a deliberately small snapshot rather than every header in a login exchange. Repeat --copy-header once per header; at least one is required. Content-Length, Transfer-Encoding and Host are refused: a slot is applied to a message with a different body and target, so copying one would make every later send under the slot misframe or misroute itself. The saved values are literal bytes, stdout redacts them as [REDACTED] unless --show-values is passed, and provenance on STDERR names the copied headers without printing their values. Slots are not host-scoped: every send that explicitly uses --slot NAME receives the slot's headers, so keep each slot limited to its intended identity.

gori run session from-request 4211 --name admin \
  --copy-header Cookie --copy-header X-CSRF-Token
gori run repeater 900 --slot admin        # send with that header snapshot

This is a literal snapshot, not a login macro: it does not re-authenticate or refresh a rotating token by itself. For short-lived JWTs, per-request CSRF values, or any credential that must be minted again, use gori run rewriter extract with --bind-from FLOW so the value is extracted anew for each run, give the slot refresh steps, or give a sweep a request-time macro (--macro) for a value that changes on every request.

Refresh steps re-authenticate a slot. --refresh 12,14 names the Repeater sessions (gori run repeater list) that log in, in the order they run: typically a CSRF fetch, then the login that carries $BIND.CSRF. Each step's response goes through the slot's own extract rules, which is what rebinds the slot. A step resolves the slot's $BIND.NAME values and carries no slot header overlay, so the login does not send the stale credential it is replacing. Every step is recorded in History with source refresh (src:refresh), and each refresh writes one event (list_events, source session) that names binding names and never a value.

--refresh-before makes the refresh run on its own, before a send that goes out as the slot (--slot NAME on any sending command, and each identity of an Authorize run):

A slot with a policy and nothing bound yet refreshes before its first send. It never retries a request after a 401: the policy acts before a send and never reads a response, so an Authorize verdict is never hidden by a login. A failed automatic refresh lets the send go ahead with the value it has, waits 30 s before trying again, and switches automatic refresh off after 3 consecutive failures until a manual refresh succeeds. Concurrent sends wait for the one refresh in flight. An automatic refresh is gated by the project scope as gori run gates any send and never inherits a command's own --allow-unscoped; the login host must be in scope. Its steps skip upstream TLS verification when the command was given -k, as its sends do.

Deleting a Repeater session that a slot uses as a step keeps the step in place, marked deleted, and a refresh refuses it rather than running whatever session takes that id next. Remove it with --refresh or --clear-refresh.

Binding values live in memory, per process: session refresh rebinds this command's own table and is gone when it exits, so it is for checking that a login sequence works. A --slot NAME sweep refreshes in its own process, and the TUI and a running gori mcp each keep their own.

There is no session activate. A gori run process sends and exits, so the active pointer has nothing to span, and persisting one would resolve into an empty binding table on the next run, sending an overlay whose $BIND.SESSION is literal. Name the identity on the send instead: --slot NAME, on send, repeater, repeater send, repeater race, repeater timing, repeater minimize, fuzz, mine, sequence, discover and retest run. The run prints slot: sending as NAME on STDERR before its first request.

run probe

gori run probe --severity high --category cors
gori run probe -a

--severity is info|low|medium|high|critical; --fail-on=LEVEL makes the scan exit 3 when an issue it reports is at or above LEVEL (after --severity/--category/--in-scope), so it can gate a CI job; --category is headers|cookies|tech|infoleak|cors|client|active|custom; -a/--active includes light-touch active checks; -q/--query filters with QL, and --lenient accepts a query that names an unknown field instead of refusing it. --in-scope reports only issues on hosts in the project's configured scope (the TUI's s lens, opt-in and independent of --active/--allow-unscoped); every flow is still scanned.

With --active: --unsafe also probes unsafe methods (POST/PUT/PATCH/DELETE), whose re-sends may mutate server data; --aggressive raises the per-rule caps and widens the forbidden-bypass header set (and implies --unsafe). Both stay scope-gated unless you also pass --allow-unscoped. -k/--insecure-upstream skips upstream TLS verification for the active re-sends. Use them only against authorized targets.

A bare probe scans and prints. --persist also writes what it found into the persisted findings, merged the way the live scanner merges them, so a project nobody opened in the TUI has a triage list; a write that does not land is reported and exits 1 after the report. The persisted findings behind the TUI's Probe tab are a separate surface:

gori run probe issues --severity high            # the triage list, with the ids the verbs below take
gori run probe promote 12                        # confirm one into Issues
gori run probe dismiss --code missing_hsts       # mute in bulk by finding code or --host
gori run probe delete --all --yes
gori run probe rules --kind active               # list scan rules and which are armed
gori run probe rules enable <rule-id>            # ids: `probe rules`, or the Probe rules reference
gori run probe mode passive                      # off | passive | active | aggressive

run discover

Spider a target and brute-force unlinked paths; findings flow into the Sitemap unless --no-store. Sends real, unsolicited traffic, so only run it against authorized targets.

gori run discover --target https://target.example --max-depth 3 --extensions php,json,bak --format jsonl

Connections are reused per origin by default, so a brute-force pass pays one TCP (and on https one TLS) handshake per worker rather than one per probe. The connections · N dialed · M reused line at the end of a run is where you see whether the target honoured it. Turn it off with --no-keep-alive when the target behaves per-connection.

run wordlist

The global wordlist catalog: named lists under $GORI_HOME/wordlists (~/.gori/wordlists), each a plain file. A name is accepted anywhere a wordlist path is (fuzz -w, mine --wordlist, discover --wordlist, cookie --crack --wordlist) from any working directory. A value with a / is a path and is read as given; a bare name is looked up in the current directory first, then in the catalog. Nothing here needs a project, and nothing sends a request. See the guide for the whole model.

gori run sitemap params --host api.example.com --format names | gori run wordlist save api-params.txt
gori run wordlist                       # what you have: names and sizes
gori run mine 42 --wordlist api-params.txt
gori run wordlist show api-params.txt --head 5
gori run wordlist rename api-params.txt api-v2-params.txt
gori run wordlist delete api-v2-params.txt --yes

A name is letters and digits of any script, _, ., +, - and inner spaces (at most 200 bytes, starting with a letter, digit or _, and not ending with . or a space); anything with a path separator is refused. All verbs take -h; a mutating verb that is refused exits 1 and says why.

Session bindings from the command line

A session binding ($BIND.SESSION filled from a login response; see Session bindings) lives in the memory of the gori process that observed it. It is never written to settings.json or to the project database: a restored token is stale by construction, and re-extracting one costs a single request.

gori run is one process per invocation, and a sweep is deliberately not an extraction source (a response echoing an attack payload back could otherwise rebind your session to it). So a headless fuzz / mine / sequence / discover whose template names a declared binding has nothing to resolve it with, and the token goes out as literal text (it is not refused).

--bind-from FLOW-ID is the missing step: it replays one captured flow, the login, through the deliberate-send path, whose response fills the binding table, and then runs the sweep in the same process.

gori run fuzz 42 --wordlist ids.txt --bind-from 17
# bind-from: flow #17 replayed → bound $BIND.SESS

Driving two gori mcp tool calls over one stdio session works the same way and always has.

run import

Bulk-import flows into the project's History, the CLI counterpart of the TUI's Import overlay (see Proxy & History → Import). Exactly one source flag is required, and every source reads stdin when its PATH is - (generator | gori run import --urls -); stdin must be a pipe or a redirect. Sends no traffic.

gori run import --postman api.postman_collection.json --db ./assessment.db --format json

Import writes flows, so it resolves its target like discover: an explicit --db is created or reopened, and without one it writes into an existing project rather than silently creating a default.

A malformed entry is skipped rather than aborting the file; the result reports both counts ({"count": 12, "attempted": 12, "skipped": 3}). When the project cannot commit every parsed flow (a busy or unwritable store), count is smaller than attempted, the text line says how many did not commit, and the command exits 1; re-run the import to retry them. Only --har and --burp carry responses; the rest import request templates that show as Pending in History until you send them.

run sitemap

gori run sitemap --in-scope --format paths

-q/--query=QL filters endpoints with the same QL as history (also positional), plus the Sitemap's own tag: for path memos (Where It Applies), -n/--limit=N caps the endpoints scanned (default 10000), --in-scope limits to in-scope hosts, --hide-static leaves out images, fonts and audio/video (per flow, like the TUI tree), --no-group disables id folding, --no-fold-query disables query-string folding (the two are separate axes), --js-refs also draws the paths captured JavaScript references and nobody requested (see sitemap js; js_refs and unrequested in JSON, and never in paths), --format is text (tree), json, or paths, and --lenient accepts a query that names an unknown field instead of refusing it.

The tree has one root per origin (scheme, host and port), so http://127.0.0.1:19021, http://127.0.0.1:19022 and https://127.0.0.1:8443 are three roots. paths prints each endpoint as a full URL (GET https://127.0.0.1:8443/only-tls), with the default port left out. Each json host object keeps host as the bare host and adds scheme, port and origin (the prefix paths prints). A tag belongs to the host, so it shows under every origin of that host.

sitemap tag: pin a free-text memo onto one path, the same note the TUI's Sitemap shows.

gori run sitemap tag --host api.example.com --path /v1/users --tag "IDOR candidate"
gori run sitemap tag --host api.example.com --path /v1/users --clear
gori run sitemap tag --list

sitemap params: the parameter inventory, the same one the TUI's Params sub-tab shows. One row per origin (scheme, host and port), method, path, location and name, with the number of flows that carried it, up to --samples distinct values (default 5), and reflected when a value of four or more bytes appears verbatim in the first 256 KiB of the decoded response body (an observation, not a finding).

gori run sitemap params --host api.example.com
gori run sitemap params 'method:POST' --location json,form --format json
gori run mine 42 --wordlist <(gori run sitemap params --host api.example.com --format names)

-q/--query=QL (also positional), --in-scope and --hide-static narrow the flows read, per flow as in history. --host is an exact host and --origin=URL one of its origins (http://127.0.0.1:19021; not with --host), --path=PREFIX a path prefix, and --location=LIST picks locations (default all). Standard browser headers are left out unless --all-headers. --max-flows=N reads the newest N matching flows (default 2000); a note on stderr says when older ones were skipped. Values of cookies, credential headers and credential-named fields such as password or token print as [REDACTED] unless --include-sensitive. Redaction goes by name and by JWT / private-key shape only, so a secret under any other name (a presigned X-Amz-Signature, a custom sig=) prints in the clear, as does one inside a URL path. Text groups rows under their origin (https://api.example.com), and json rows carry scheme, host and port. --format is text, json, or names (one name per line, JSON leaf names, no headers unless --location names them), which is a Miner or Fuzzer wordlist.

sitemap js: the endpoints captured JavaScript references, the same ones the TUI's Sitemap draws as js rows. By default it lists only the ones no captured request reached on their own origin, grouped by origin (http://h:9090 and https://h are two groups), each with the flow and line it was read from, the literal, and flags (comment, templated, base: referer|guessed).

gori run sitemap js --scan
gori run sitemap js --host api.example.com --format json
gori run sitemap js --format urls | httpx -silent

--scan first reads the captured JavaScript responses and HTML pages no scan has read yet (newest first, --max-flows of them, default 500) and stores what they reference. It sends nothing; -q/--query=QL (also positional) narrows the flows it reads, and --rescan reads already-scanned ones again. The listing takes --host (exact), --path=PREFIX, --all (also references traffic already reached), --all-hosts (also hosts gori never captured and no scope include names, which are hidden by default), --no-comments and --in-scope. --format is text, json or urls (one URL per line; templated references, which are not sendable as-is, are left out). The references are deleted with their source flows.

sitemap export: the captured API as an OpenAPI 3.0.3 document on stdout, the same one ⇧E on the TUI's Sitemap writes. What was left out and why goes to stderr.

gori run sitemap export --host api.example.com > api.json
gori run sitemap export --host api.example.com --format openapi-yaml > api.yaml
gori run sitemap export --origin http://127.0.0.1:19021 > one-service.json
gori run sitemap export --in-scope --examples > api.json

• Paths are templated one path at a time. A numeric, UUID, long-hex or date segment becomes a parameter named after the segment before it, so /users/123/orders/9f1c2b7d0a4e becomes /users/{userId}/orders/{orderId}. A single captured id is enough; the tree's display folding waits for many. Endpoints whose templates match merge into one operation. Query-string variants of one path are one operation too.
• Parameters (query, header, cookie) are required only when every sample of the operation carried them. Standard browser headers are left out, and a repeated query key is an array.
• Bodies: request bodies and responses per status carry a schema inferred from every sample. A JSON schema merges types (integer and number become number, and genuinely different types become oneOf), unions object properties and requires the members every sample had. Forms become object schemas, and other media types a string.
• Security: an Authorization header becomes an http bearer, basic or digest scheme. Another credential header (X-Api-Key, X-Auth-Token, …) and a session cookie become apiKey schemes. Their values are never written.
• Skipped: requests gori sent itself (Repeater, Fuzzer, Miner, Discover and the other tools; --include-gori keeps them), WebSocket, gRPC, SSE and incomplete flows, and methods OpenAPI has no slot for (CONNECT, WebDAV). Each is counted on stderr. Without that first rule, a Discover brute force would add every path it guessed and a fuzz run would loosen every type.

-q/--query=QL (also positional), --in-scope and --hide-static narrow the flows read, per flow as in history. --host is an exact host, and --path=PREFIX is a path prefix. When the flows span several hosts, one document lists every origin under servers and each path lists the ones that answered it; use --host for one API per document. --max-samples=N (default 20) caps the flows read per operation, --max-flows=N (default 5000) the flows read in all, and --max-endpoints=N (default 1000) the operations kept. A note on stderr says when a cap cut the document short.

There are no example values unless --examples. Examples come from one sample each and pass the redaction profile (--redact=PROFILE, by default the project's, else the global one, else default). The profile's field and form-key names apply to query parameters too. A name that reads as a credential (X-Access-Token, apiKey, userPassword, sig) is a placeholder whatever the profile says, and cookie values always are. A path id gets an example only when it is a short counter or a date under a segment that does not name a secret; a UUID, hex or token-shaped segment never does, because a credential in a path looks the same. Token-shaped path segments (a JWT, a long random string) and ;jsessionid=-style matrix parameters never reach the path key. Output is deterministic: exporting the same flows twice gives the same bytes, so diff between two exports shows how the API changed.

run oast

Out-of-band listener. listen is ad-hoc and store-free by default (register a payload, print it, stream callbacks); --save makes it a project session instead. list / resume / release act on those saved sessions, the same rows the TUI's RESUME LISTENER picker shows.

gori run oast presets                          # list built-in public providers
gori run oast presets --check                  # …and probe each one for reachability
gori run oast listen                           # interactsh, poll until Ctrl-C
gori run oast listen --provider webhook.site --once --json
gori run oast listen --save                    # …and keep it as a project session

presets lists the public providers, and presets --check PROBES each one over the network and prints the stage it fails at (dns / connect / proxy / tls-verify / tls / timeout / exchange / dial), which is what separates a custom trust store or a restricted resolver from a provider outage. It exits non-zero only when nothing answered.

gori run oast presets --check
gori run oast presets --check --format json

A failed listen names the same stage. On tls-verify the remedy is this machine's trust store, not another provider: run with SSL_CERT_FILE=/path/to/ca-bundle.crt (or SSL_CERT_DIR=/path/to/certs) so the private or TLS-inspecting CA is trusted. For gori's own service traffic that bundle is additive (the system store is still loaded), so the public presets keep working. There is no --ca-file flag.

listen options:

--save is what turns an ad-hoc listener into a project one, and it changes three things: every callback is written into the project (so the TUI OAST tab shows the same hits), the registration is kept on exit so oast resume ID can pick it up later, and the out-of-band probe rules (ssrf_oast, xxe_oast, cmd_injection_oast, rfi_oast) have a session to mint payloads against. Without one they plan nothing and gori run probe --active says so. It takes --project / --db like the session verbs; oast release ID is the teardown.

oast list / resume / release: the project's saved listening SESSIONS, as opposed to the providers below (a provider is where you listen; a session is one live registration on it). A registration outlives the process that minted it, which is what makes a payload planted yesterday still worth watching.

gori run oast list                                       # id, provider, payload host, hits, last poll
gori run oast list --format json
gori run oast resume 7                                   # re-arm session #7, stream its callbacks
gori run oast resume 7 --once --json                     # one poll, JSON lines, then exit
gori run oast release 7                                  # deregister it server-side

resume and release take the session id (7, or the #7 list prints). resume re-arms the server-side state so payloads already planted keep resolving, then polls: every callback is written into the project, so the TUI OAST tab shows the same hits, and last_poll_at is stamped like a TUI listener's. Ctrl-C stops polling and keeps the registration. release is the deliberate teardown, and it keeps the stored callbacks either way. Nothing auto-resumes; these run only when you ask.

oast providers: the saved providers stored with the project, as opposed to the ad-hoc listen above. Verbs: list (default), add, update, enable, disable, delete (rm).

gori run oast providers                                  # tokens print as [REDACTED]
gori run oast providers add --name lab --kind custom-http --host https://oast.lab.internal
gori run oast providers enable p_1

enable, disable, update and delete take the provider id (p_1, or a bare 1), not its display name; add prints the id it assigned, and list shows it. list also shows the global providers from settings.json as g_<hex>; those are read-only here.

run jwt

Decode, verify, re-sign, or generate attack payloads for a JWT. Store-free compute; the token comes from the <token> argument or stdin. An encrypted five-part token (JWE) decodes to its protected header: gori reads alg/enc/kid and does not decrypt the claims.

gori run jwt eyJhbGci...                        # decode (default)
gori run jwt eyJhbGci... --encode --alg HS256 --secret s3cret
gori run jwt eyJhbGci... --encode --set role=admin --secret s3cret
gori run jwt eyJhbGci... --encode --alg ES256 --key ./private.pem
gori run jwt eyJhbGci... --verify --key ./public.pem
gori run jwt eyJhbGci... --attacks --key ./public.pem

run cookie

Decode, verify, brute-force, or forge a signed Flask / Rack / Django session cookie. Store-free compute; the cookie comes from the <cookie> argument or stdin.

gori run cookie 'eyJ1c2VyIjoi...'                            # decode (default), format auto-detected
gori run cookie 'eyJ1c2VyIjoi...' --crack --wordlist secrets.txt
gori run cookie --forge --type flask --secret s3cret --payload '{"user":"admin"}'

run decoder

Run a Decoder chain over a value. Steps are separated by |, >, or ,.

A step written exec:COMMAND is an external process hook instead of a converter: the running value goes to COMMAND on stdin and its stdout becomes the step's output. It is exec'd with no shell, so the three separators cannot appear in its arguments.

gori run decoder 'base64-decode | jwt-decode' "$TOKEN"
echo -n secret | gori run decoder 'sha256 | base64'
gori run decoder 'base64-decode > exec:./parse-envelope --json' "$BLOB"
gori run decoder list                           # every converter (name, category, direction)

run issues / notes

gori run issues --format markdown --export report.md
gori run issues --format sarif --export issues.sarif    # upload to GitHub code scanning / a CI dashboard
gori run notes --all

Write issues from scripts with create / update:

gori run issues create --title "Reflected XSS on /search" --cvss 8.8 --host app.example.com --flow 42
gori run issues update 7 --status confirmed --notes "Verified on staging" --severity critical
gori run issues delete 7 --yes

# The notes body can come from a file or a pipe instead of the argument vector
gori run issues create --title "IDOR on /v1/users/{id}" --severity high --notes-file writeup.md
report-generator | gori run issues update 7 --status confirmed --notes-stdin

--notes, --notes-file and --notes-stdin are mutually exclusive, and the body is read byte-for-byte, multiline UTF-8 and CRLF included (the value of a bound project env var is still masked to $ENV.NAME on the way in, as it is for every issue field). A long write-up piped in or read from a file stays out of the process listing and the shell history; on create it is written with the issue in one transaction, so a script does not need a create-then-update pair. --notes '' clears the notes on update; a file or a pipe that yields nothing is refused instead, so a report generator that dies cannot silently erase a write-up. --notes-stdin needs a pipe or a redirect (--notes-stdin < notes.md) and refuses a terminal, for the same reason --request-stdin does.

--format sarif writes a SARIF 2.1.0 log, the format GitHub code scanning, DefectDojo and Azure DevOps ingest. Each issue becomes one result: its severity maps to a SARIF level (with rank and the rule's security-severity preserving the full five-way scale), a false-positive or resolved triage status becomes a suppression so a dismissed finding does not reappear as open, and a linked flow rides along as webRequest/webResponse with real headers and (decoded, 64 KiB-capped) bodies.

Credential header values are [REDACTED] in that log by default, and the message is marked gori/sensitiveHeadersRedacted: true when anything was withheld. A SARIF log is made to leave the machine, so it gets the same default as history --format json and evidence show; --include-sensitive writes the exact values. A repeated header is combined the way that field allows: list values with , , Cookie pairs with ; . Set-Cookie never combines, so its fields are joined with a newline and also listed one per field in the message's gori/setCookie property.

Notes are readable and writable too. notes with no argument lists them (* marks the active note); notes <n> prints one by index:

gori run notes                                  # list
gori run notes 2                                # print note 2
gori run notes create --text "SSRF candidate on /fetch"
echo "pasted from a scratchpad" | gori run notes create
gori run notes append 1 "confirmed on staging"
gori run notes update 1 --text "rewritten from scratch"
gori run notes delete 2 --yes

A note is prose that exists nowhere else (no capture or re-run reproduces one), and the index is a list position, so notes delete 2 names a different note once an earlier one is gone. delete therefore refuses without -y/--yes (there is no interactive prompt), and the refusal quotes the note's first line, when it has one, so a wrong number is visible before it costs anything.

run notify

notify is how a script reaches the operator in the TUI, the way an agent does with MCP reply_to_operator. The summary is one line for the notification ring and Miss Ring's bubble; --detail (or --detail-file, - for STDIN) is the long form the ring opens on ↵:

gori run fuzz --flow 42 --auto --preset sqli > hits.txt && gori run notify "fuzz on flow 42 done" --level success --detail-file hits.txt
./nightly-scan.sh 2>&1 | tail -20 | gori run notify "nightly scan finished" --detail-file -

The line is written to the project's event feed under the script source, so the ring shows it without the ai marker an agent's reply carries, and the Activity pane can filter it. It is written whether or not a TUI is open, and notify exits 0 either way; the output says whether a window was there to show it. When none was, the next TUI to open on the project sums it up in one note along with any agent replies that also arrived while it was closed.

run links

The evidence an Issue or Note points at: a captured Flow, a Repeater session, or a Fuzz / Miner run. The Markdown issue export resolves these already; this is the surface that lists and edits them.

gori run links --owner=issue --id=7
gori run links add --owner=issue --id=7 --ref=flow --ref-id=42
gori run links delete --owner=note --id=2 --ref=repeater --ref-id=3

A pointer whose target was pruned lists as (stale) rather than disappearing, so "no evidence" and "evidence that is gone" stay distinguishable. add is idempotent, and both ends must exist.

run evidence

An Issue's frozen evidence: the immutable copy of one exchange, taken from a captured Flow or a Repeater tab at the moment it proved the finding. links is the live-source pointer; this is the archived bytes. The Repeater's next send and History retention cannot reach a copy, so freeze once when a response confirms a finding and again after the retest. One snapshot can be linked to several Issues, and removing its last Issue link leaves it orphaned until it is linked again or explicitly deleted.

gori run evidence freeze --issue=7 --ref=repeater --ref-id=3       # copy + the live link
gori run evidence freeze --issue=7 --ref=flow --ref-id=42 --no-link
gori run evidence --issue=7                                        # list: source, time, status, size, SHA-256
gori run evidence                                                  # the whole project archive, orphans included
gori run evidence show 12                                          # the copy, credentials redacted
gori run evidence show 12 --include-sensitive --format=json
gori run evidence link 12 --issue=9                                # add another Issue membership
gori run evidence unlink 12 --issue=7                              # snapshot remains if orphaned
gori run evidence delete 12 --yes

A Repeater tab that has never been sent is refused rather than frozen request-only, and so is a flow whose response has not landed. A Repeater copy pairs the tab's saved request (bindings unexpanded) with the last response the store holds for it (a successful send's), so freeze right after the send that proved the finding.

Request drift. A Repeater tab holds one request and one response, and editing the request does not change the response beside it: send, edit, freeze, and the copy pairs an edited request with an earlier exchange's response. gori records the SHA-256 of the request each send actually went out with, so it can tell: freeze refuses such a tab by name and tells you to send it again, --allow-drift writes the mismatched pair anyway, and the TUI asks before it writes. A response persisted by a gori older than this one has no recorded digest; those are treated as unknown, not as drift. A WebSocket copy is the handshake; the frame transcript is not copied. A project's frozen evidence is bounded at 256 MB; past that freeze refuses until a copy is deleted. show decodes bodies and cuts the text form at 64 KB (the stored copy is complete); the JSON form takes the same shape get_flow returns.

run retest

An Issue's retest: the ordered Repeater sends that reproduce the finding, each with a role and at most one assertion, plus the bounded record of what happened the last few times it ran. links says what is related and evidence keeps the bytes that proved it; neither can be run. This is what turns "send #4 to log in, then #5 should answer 403" out of an issue's write-up into something CI can execute.

gori run retest add --issue=7 --repeater=4 --role=setup                        # log in first
gori run retest add --issue=7 --repeater=5 --role=baseline --assert=status:200
gori run retest add --issue=7 --repeater=6 --role=variant  --assert=status:403
gori run retest --issue=7                                                      # the plan, with what each step will send
gori run retest move 9 --to=1                                                  # reorder (ids from --format=json)
gori run retest update 9 --role=control --assert=body:same
gori run retest remove 9                                                       # drop one step (`rm` is accepted)
gori run retest clear --issue=7 --yes                                          # delete every step
gori run retest run --issue=7                                                  # exit 0 only on `pass`
gori run retest runs --issue=7                                                 # the bounded run history
gori run retest show 3                                                         # one run's result table
gori run retest forget 3                                                       # drop one run from the record

forget RUN drops one run summary and its result rows. The steps that produced it stay, and so do the History flows each send recorded: it removes the report, not the evidence. The history prunes itself to the newest 20, so this is for the run that should not be on the record (a batch sent at the wrong target, or under a scope since fixed).

Assertions, one per step:

A JSON path is the same one sequence --jsonpath takes: dotted (data.items.0.id) or bracketed ($.data.items[0]["id"]). A path gori cannot read (a wildcard, a filter, .., an unclosed bracket) is refused when the step is added, so a json-absent: can never pass just because its path was never read. A readable path to a field that is not there is an ordinary absence.

A step sends whatever its Repeater tab holds when the run happens. That is what makes a retest track a request as it is fixed, where gori run evidence freezes one as it was. Each send goes out under the project's scope and Sandbox gates and is recorded in History as src:retest with the issue and step on the row, so a result row still opens the exact response it reported long after the tab moved on. The tab's own stored response is never overwritten.

A setup step that fails halts the measurement steps (its precondition is what everything after it measures against) but cleanup still runs. Once gori refuses a send (scope, Sandbox, an exclude rule), the rest of the run is skipped, cleanup included, unless --allow-cleanup says otherwise; every skipped step still gets a row saying why, so a partial run can never read as a pass. A body: assertion is inconclusive, never a pass, when there is no baseline behind it, and equally when the last baseline step missed its own expected result: a baseline that did not establish its reading anchors nothing, so comparing a variant against the 403 error page a status:200 baseline was handed would otherwise report "the body is unchanged" about two error pages.

The verdict is pass only when every step ran and every assertion was decided; blocked outranks fail, because a run gori refused to finish is a fact about the scope configuration and not about the target. run exits 0 on pass and 1 otherwise. The newest 20 runs per Issue are kept.

run rewriter

Manage Match & Replace rules from scripts. The same rules the Rewriter tab edits, applied to live proxy traffic:

gori run rewriter                                       # list rules in apply order
gori run rewriter add --op set_header --target request \
  --find X-Forwarded-For --value 127.0.0.1 --host '*.example.com'
gori run rewriter add --op replace --target response --part body \
  --match regex --find 'secret=(\w+)' --value 'secret=[redacted]'
gori run rewriter add --op remove_header --target response \
  --find Content-Security-Policy --scope global          # applies in EVERY project
gori run rewriter preview --op replace --part body --find password --value hunter2
gori run rewriter add --op short_circuit --map-dir ./tampered \
  --strip-prefix /static/ --fallthrough                 # missing files reach the origin
gori run rewriter add --op short_circuit --find /api/pay --fault reset
gori run rewriter add --op short_circuit --from-flow 42  # a captured response as the stub
gori run rewriter disable 3
gori run rewriter disable 2 --scope global               # off in THIS project only
gori run rewriter disable 2 --scope global --everywhere  # off by default, everywhere
gori run rewriter rm 3

preview takes the same rule flags and reports how many stored flows the rule would have changed, without writing it. rm (delete), enable and disable take a rule id from the list, plus --scope, because the two stores number their rules independently, so an id alone names two different rules. The list prints the scope as a G/P prefix (G* = this project overrides that global rule's default) and shows global rules first, the order the proxy applies them in. See Global and project rules.

Body rules re-sync Content-Length and de-chunk as needed, on HTTP/1.1 and HTTP/2 alike. See Proxy & History for the interactive editor.

rewriter preset: install a response-modification preset, a named starting point that writes ordinary Match & Replace rules. Verbs: list and add <name>.

gori run rewriter preset list
gori run rewriter preset add unhide-hidden-fields
gori run rewriter preset add remove-csp --scope global --disabled

Names are unhide-hidden-fields, enable-disabled-fields, remove-length-limits, strip-validation, remove-csp, remove-security-headers and disable-sri. add takes --scope=project|global and --disabled (install without arming, to review them first). The rules it writes go through the same path rewriter add does, so they are listed, editable and deletable afterwards. Installing the same preset twice duplicates visibly rather than merging.

rewriter extract: the rules that declare session bindings: which response a $BIND.NAME is read from, and where in it. Verbs: list (default), add, rm (delete), enable, disable.

gori run rewriter extract add --name SESS --kind cookie --selector session --host '*.example.com'
gori run rewriter extract add --name CSRF --kind regex --selector 'name="csrf" value="([^"]+)"'

rewriter bindings: list the names those rules declare (--format text|json). Values are not shown here and cannot be: a binding's value lives in the memory of the running gori and is never written anywhere, so another process has nothing to read. The Rewriter tab's bindings sub-tab shows the live table. For a headless sweep, --bind-from fills the values in-process; see Session bindings from the command line.

run grpc

The gRPC .proto lens from the command line: what schema this project renders captured gRPC through, and where each piece came from.

gori run grpc                                  # what is loaded (schema is the default verb)
gori run grpc schema --format json
gori run grpc reflect https://api.test:443     # ACTIVE: ask the target for its descriptors
gori run grpc forget https://api.test:443      # drop one cached target (`rm` is accepted)
gori run grpc forget --all

schema and forget touch nothing outside the project database. reflect is the one that sends: it asks the target's grpc.reflection.v1 service (falling back to v1alpha, still what most deployed servers expose) for the services, then the file declaring each one, then their imports until the graph closes, and caches the result in the project. It goes through the same scope gate every other active gori run command does, so an out-of-scope target is refused before the dialer. A server that answers neither reflection version says so rather than failing quietly, and nothing ever re-fetches on its own.

A descriptor-set file (Project settings → Proto schema) is not unloaded by forget; clear the path in the project's settings instead. Where a file and a reflection fetch disagree about a declaration, the count is reported as redefined and the target's own word wins.

run colormarker

Manage Colormarker rules: which captured History rows get coloured, and how. Display only: a colour rule never modifies traffic, so unlike a Match & Replace rule it costs a misleading list at worst, never a modified message.

gori run colormarker                                        # list rules in precedence order
gori run colormarker add --when 'status:>=500' --color red --style full --name 'prod 5xx'
gori run colormarker add --when 'host:cdn' --color blue --style strip --scope global
gori run colormarker update 2 --color orange                # edit in place, keeping precedence
gori run colormarker move 2 --up                            # higher precedence
gori run colormarker preview --when 'method:DELETE'
gori run colormarker preview --when 'resp.body:secret' --scope global
gori run colormarker disable 1 --scope global               # off in THIS project only
gori run colormarker disable 1 --scope global --everywhere  # off by default, everywhere
gori run colormarker rm 3

On update every field is optional and defaults to the rule's current value, so --color alone is a recolour and --when alone a re-aim. Use it rather than delete + re-add: a colour rule's position is its meaning (the first enabled match paints the row), and a re-added rule lands at the end of its scope block, outranking nothing it used to outrank. enable / disable stay separate, because for a global rule they are a statement about this project rather than the library.

Precedence is the rule set's meaning. Match & Replace rules compose: every enabled rule runs, in order. Colour rules resolve: the first enabled match paints the row and the rest are never consulted. That is why move exists here and not on rewriter. Global rules resolve before project ones, so a standing policy outranks a local layer.

--when is a History QL condition: the same grammar, the same field set and the same answers as the filter bar above the list it paints, ~regex and AND / OR / NOT / -negation / (grouping) included. A term the captured row can answer (host: path: url: method: scheme: status: proto:) is matched in memory with no query at all; the rest (body: header: size: dur: stub: static: src: scope:) resolve against the project database in one batched query per rule per repaint. Four caveats, each of which would otherwise fail silently, so gori refuses or warns rather than letting you find out from a list that never turns colour:

• body: scans here, it does not read the text index. So a colour rule reaches binary bodies the filter bar's body: skips, but only the first 64 KiB of each side, and the bytes are as captured, so a match past that bound or inside a compressed body is not painted. (Warned.)
• host: is a substring, not a DNS-label glob. host:alpha.test also matches xalpha.test. (Warned.)
• A flow with no response yet has no status. A status: rule paints the row once the response lands. (Warned.)
• scope: follows the project's scope rules and ignores the s display lens. With no scope rules configured nothing is in scope, so scope:in and scope:out both paint nothing, while a negated one (-scope:in) paints every row. (Warned.)

Refused, rather than warned: an unknown field (left alone, hsot: becomes a free-text search and the rule never fires), a ~ pattern that will not compile, a term whose value that field does not take (size:>bogus, which would be dropped and leave the rule painting more than it says), and a condition that matches every flow (empty, or a half-typed host:).

preview reports how many recent flows the condition matches and how many it would actually paint. The two differ whenever an earlier enabled rule already claims the row, which is why preview takes --scope as well: every global rule resolves before every project one, so no project rule can claim a row from a --scope=global candidate. update, rm (delete), enable, disable and move take a rule id from the list, and --scope, because the two stores number their rules independently, so an id alone names two different rules. The list prints the scope as a G/P prefix (G* = this project overrides that global rule's default).

The tab is off the bar by default; 0 opens it, or settings:tabs gives it a slot next to Rewriter. See Proxy & History for the interactive editor.

colormarker color

The custom colour palette: named colours the picker offers in every project on top of the six built-ins. A built-in resolves through the active theme, so it reads correctly on light and dark alike; a custom carries an absolute hex and does not track the theme. That is the trade for a hue the palette does not provide. Colours live in settings.json (colormarker.colors), so they are global by construction.

gori run colormarker color list
gori run colormarker color add --name hotpink --hex '#ff69b4'
gori run colormarker color update hotpink --hex '#e0559b'   # recolour, keep the name
gori run colormarker color update hotpink --name fuchsia    # rename, keep the hex
gori run colormarker color rm fuchsia
gori run colormarker add --when 'method:DELETE' --color hotpink

The name is the identity (it is what a rule's --color stores and what the picker shows), so it is lowercased, must be unique, and may not be one of the built-in words. update takes either half alone.

Deleting or renaming a colour deliberately does not rewrite the rules that name it: they keep the reference and fall back to a visible default, so re-adding the colour restores them. gori cannot reach every project's database from here, and a half-applied cascade would be worse than a dangling name. Recolouring is different: a rule references a colour by name, so it follows the new hex everywhere.

run views

Manage History views: named QL queries the History list narrows to. A view is a lens: it is ANDed over whatever else is filtering rather than replacing it, so gori run history --view History -q 'status:5xx' means both. Seven built-ins ship with every project: the source trio All / History (src:proxy) / History + Repeater (the default), plus WebSocket, gRPC, SSE and Errors. Saved views live in two stores exactly as colour rules do.

gori run views                                              # list; the TUI's active view is marked ●
gori run views --scope global --format json
gori run views add 'acme errors' -q 'host:api.acme.test status:5xx'
gori run views add 'proxied' -q 'src:proxy' --scope global
gori run views set 'acme errors' -q 'status:>=500'          # new query, same name
gori run views rename 'acme errors' --to 'acme 5xx'
gori run views scope 'acme 5xx' --to global                 # re-home between the two stores
gori run views rm 'acme 5xx' --scope global

A view is addressed by name, because that is what --view and the picker take; an id would be a second spelling of one thing. Names are unique within a scope and may collide across them; --view then resolves project → global → built-in, the same precedence project env vars and host overrides already follow. Every mutator takes --scope for the same reason colormarker rm does: the two stores are independently addressable, and guessing which one you meant would edit the wrong view. The listing prints the scope as a G/P/· prefix.

The query is validated on the way in, not when it runs. A query naming an unknown field, holding a broken regex, or one whose every term would be dropped is refused. That last one is the important one, because a view that narrows nothing would still show a v: chip claiming it does. The same check runs at all three surfaces, so a view the TUI refuses is not one the CLI accepts.

Built-in views cannot be edited or deleted, and a saved view may not take a built-in's name: it would shadow it, and --view could never reach the built-in again.

Deleting the view a project is currently looking through drops that project back to All. Another project's pointer at a global view you delete stays inert: ids come from a monotonic counter and are never reused, so nothing can inherit it. See Proxy & History for the interactive picker.

run project

List, create, export, import, or delete projects, or manage project-scoped config (scope rules, env vars, host overrides):

gori run project --format json
gori run project list
gori run project list --all
gori run project list --query=acme

list hides the empty projects (zero captured flows), because a project per worktree or per checkout accumulates into hundreds of them and buries the two or three holding traffic. Emptiness is counted, not inferred from file size: a project created a second ago is the same size as a leftover from March. Two are always listed however empty they are, and marked: ◆ is the project a --project-less gori run reads, ◇ the one the TUI last opened. In --format json those are the current and tui_active fields, beside a flows count and the project description (read in the same pass as the count, so it costs no extra open); the count of what was hidden goes to stderr, so a JSON pipe stays a clean array.

--query is the other half of that: a substring of any spelling that addresses a project, so a half-remembered name finds it. It is looser than --project, which wants an exact name, slug or short id. It is applied before the flow census, which opens every listed project's database, so a query is also the fast path on a host holding hundreds. It is orthogonal to --all, and it narrows the row source rather than the display, so what it excludes is said on stderr: a query that matched nothing reports how many projects the host actually has, and a query that filtered out the ◆ project names it: unlike the empty-hiding default, --query does not pin that row. --format json carries the bound workspace beside the rest, so a consumer can filter on the same fact the query does. The same narrowing is MCP list_projects{query}, over the same predicate.

project create

Create a project without capturing into it first. gori run capture --project=NAME also creates on demand; this is the traffic-free way to do it, so scripts can set up scope and env before the proxy starts.

gori run project create "API test"
gori run project create api-test --description="staging sweep"
gori run project create api-test --format json

A name that already exists reopens that project instead of failing; --format json reports it as "created": false. The reopen rewrites the stored display name (so its casing follows the last create) and replaces the description when --description is given. A new name that is already another project's directory slug or short id is refused, since --project could not then reach the project it made.

project switch

Pin the project every --project-less gori run command reads, instead of the most-recently-active one, which a single write to any other project moves:

gori run project switch api-test     # pin (by name, slug or short id)
gori run project switch              # print the default and what chose it
gori run project switch --clear      # back to the most-recently-active project
GORI_PROJECT=api-test gori run history   # a per-process pin, for one script

GORI_PROJECT wins over the pin, and --project/--db win over both. A pin or GORI_PROJECT that names no project is refused rather than skipped, and deleting the pinned project clears the pin. project list marks whichever one is in force with ◆, and --format json on switch reports project, id, source (env, pinned or recent) and pinned. gori mcp and the TUI do not read it: MCP has its own binding (GORI_MCP_PROJECT, the workspace), and the TUI opens what you pick.

project export

Export one project's database, including committed writes still in its WAL, to a compact archive. The source project stays open and unchanged.

gori run project export "API test" -o engagement.gori
gori run project export api-test --output=before-clear.gori --force

Before writing, gori prints flow, session-slot and project env-var counts, and whether project upstream credentials are set, to stderr. The archive copies the full database as stored, without redaction, and is created with owner-only file permissions. Existing files are refused unless --force is given; the destination cannot be inside the source project directory.

project import

Validate an archive and register it as a separate project. Import never replaces or reopens an existing project.

gori run project import engagement.gori
gori run project import engagement.gori --name "API test copy"

Before creating the project, gori prints the archive's flow, session-slot and env-var counts, and whether project upstream credentials are set, to stderr. An existing display name, directory slug, or short id is refused, and the refusal names --name to resolve it. The imported project gets a new short id and no machine-local workspace binding or lock files. Older database schemas migrate when the project is first opened; a schema newer than this build supports is rejected. Import adds the project to the registry but does not open it.

The copy is imported as data, never as this machine's configuration or anything that runs: it drops the project's network settings (net.*), host overrides, Rewriter/Colormarker global-rule overrides and Probe mode, turns off every session slot's auto-refresh, and disables pipe rules, file-backed short-circuit rules and exec custom probe rules. Re-enable what you trust after reviewing it.

project delete

Delete a project directory and everything captured in it (flows, issues, notes, scope, rules). Irreversible, so it takes two steps: without --yes it only prints the target and exits non-zero.

gori run project delete api-test              # preview only, nothing is removed
gori run project delete api-test --format json
gori run project rm api-test --yes            # actually delete

The preview reports flow and issue counts, on-disk size, and both of the locks the delete honours: whether a capture is live (capture_lock_held) and whether any other gori instance has the database open (open_in_another_instance; an MCP server takes no capture lock and still writes to it). deletable is the verdict those two add up to, and the closing line says whether --yes would go through. Deleting a project either one covers is refused: stop that capture, or close it there, first. A capture_lock_held of null means the lock could not be read at all (an unwritable project directory), which the delete also refuses.

Display names are not unique (two workspaces with the same basename share one). When a name matches more than one project, delete refuses and lists their slugs and short ids, as every --project does, since the wrong guess is unrecoverable. Slugs and short ids are unique, so either always resolves.

project scope

Manage the project's include/exclude scope rules from scripts:

gori run project scope                                          # list rules + enabled state
gori run project scope --format json
gori run project scope add --kind=include --type=host --pattern=api.example.com
gori run project scope add --kind=exclude --type=regex --pattern='.*\.(css|js)$'
gori run project scope delete 3
gori run project scope enable
gori run project scope disable

The listing prints a second line for the other thing the rules do: Active-send gate: ON (N rules) whenever a rule exists, enabled or not, because every active send (send, repeater, fuzz, mine, discover, MCP) refuses a target the rules leave out of scope unless --allow-unscoped. --format json carries it as active_send_gate. With no rules, gori run sends are unrestricted and MCP refuses every send.

project sandbox

Get or set the hard-containment sandbox gate, the headless equivalent of the TUI Project settings toggle. When on, the capture proxy forwards only requests the scope allows and blocks everything else. This is distinct from project scope enable, which is only the display lens.

gori run project sandbox                 # show the current state (status is the default)
gori run project sandbox status --format json
gori run project sandbox on              # start blocking out-of-scope traffic
gori run project sandbox off             # stop blocking

With no include rule, turning the sandbox on blocks all captured traffic until you add one (gori run project scope add …). The command warns and proceeds, so it can bootstrap containment for CI.

project env

Manage project env vars used for $ENV.KEY substitution in outbound requests (Repeater, Fuzzer, Miner, CLI, MCP). Global vars live in settings.json / the TUI Settings. This command only touches the per-project layer. The name is stored bare; which grammar spells it on the wire is global, and gori settings env-syntax decides it.

gori run project env                              # list KEY=[REDACTED] (--show-values prints values)
gori run project env --format json
gori run project env set TOKEN=secret
gori run project env set HOST api.example.com
gori run project env delete TOKEN

project host-override

Manage project host overrides: /etc/hosts-style maps that change only the TCP dial target (SNI, certificate hostname, and Host header stay the original name). The value may carry a port (IP, IP:PORT or [v6]:PORT), so a hostname can be redirected at a listener on a different port; a bare IP keeps the request's own port. Project entries win over the global hostname overrides on collision. Alias: host-overrides.

gori run project host-override                              # list
gori run project host-override --format json
gori run project host-override add --host=api.example.com --ip=10.0.0.1
gori run project host-override add 10.0.0.1 api.example.com   # /etc/hosts order
gori run project host-override add --host=api.example.com --ip=127.0.0.1:8443   # move the port too
gori run project host-override update 1 --host=api.example.com --ip=10.0.0.9
gori run project host-override delete 1

project network

Read and edit the project's own network settings, the net.* rows the TUI's Project settings card writes. A value set here wins over the global network.* in settings.json for this project only; unset returns the key to the global value. See Per-Project Overrides for what each key does and where it applies. Alias: net.

gori run project network                                   # every key: its value here, and where it comes from
gori run project network --format json
gori run project network set upstream_proxy=http://proxy.corp.example:3128
gori run project network get upstream_proxy
printf %s "$PROXY_PASS" | gori run project network set upstream_auth alice --password-stdin
gori run project network set capture_max_mib 16
gori run project network unset capture_max_mib
gori run project network set outbound_max_rps=10          # every run, every process, together

Credentials pin the upstream they were entered for, as they do in the Project settings card: set upstream_auth also pins an inherited global upstream to the project, in the same write, so the password can never follow a later global edit or an upstream rule to a different proxy; set upstream_proxy moves stored credentials to the new address (re-deriving Basic vs SOCKS5 for it); and unset upstream_proxy is refused until unset upstream_auth. The multi-row edits are one transaction, so a busy project cannot store a password beside an address it was not validated against. Every edit is recorded in the project's event feed, without the credential.

A gori that already has the project open (a TUI, a capture, an MCP server) read these rows when it opened the project and keeps them until the project is reopened there; the command says so on STDERR when that is the case.

run redact

Manage the redaction profiles that safe evidence export applies, and where they apply.

gori run redact profiles
gori run redact set pci --json-field card_number --json-field cvv --json-pointer /data/acct
gori run redact use pci
gori run redact default on

set takes four kinds of rule, each repeatable, plus --description:

Scopes. A profile lives in the project database or in settings.json, and which one is part of what it is. "Never export a password field" is the operator's own policy and belongs global; "this target calls it pwd_hash, and the account number is at /data/acct" is engagement data that must not follow you into the next engagement. Resolution is most-specific-first (project, then global, then built-in), and the first match by name wins, so a project profile shadows a global one and a global one shadows a built-in of the same name.

The built-in default covers credentials, tokens and the common government/financial identifiers by field name (password, client_secret, access_token, api_key, session_id, otp, pin, ssn, card_number, cvv, iban, …) and carries no regexes: a shipped pattern that fires on the wrong thing costs a mangled report with no warning, while a shipped name that does costs one value that was probably worth losing. It deliberately says nothing about, say, email: a default that redacted those would wreck the evidence for the class of finding where the address is the finding. Add what you want to a profile of your own, where you can see it.

default on is opt-in, once. Flipping it under an install that already has scripts reading gori run show --format raw would silently change what they get, so gori ships it off; from then on --no-redact is the explicit path back to the captured bytes, per invocation. With it on, the TUI's Space → Y copy menu and MCP get_flow sanitize too: a copy heading reads COPY REQUEST AS · SANITIZED (3), and get_flow returns a body_redaction object naming the profile, the counts and what it did not look at. MCP's include_sensitive: true turns body redaction off along with the header redaction: one flag, both axes.

Placeholder tags are [REDACTED:<8 hex>], an HMAC of the value under a secret minted once per install and kept in settings.json. Equal values share a tag so a report can still correlate them; nothing can be recovered from one, and a tag means nothing outside this install. A factory reset keeps the salt, because discarding it would break every placeholder in every artifact already written. gori settings export --sections redaction carries the salt as well as the rules; hand somebody gori run redact profiles --format json instead when you mean to share only the rules.

gori mcp

MCP stdio server. See the MCP guide for tool details.

Several --install-* flags may be given in one run; each named client is configured and reported separately, and one unwritable config does not stop the others. Every other flag on the command line (--db, --project, --no-project, --use-active-project, --read-only, --tools, --pin-project, --insecure-upstream, and the global --config) is written into the installed command, with paths made absolute (--project is recorded as the name). Existing config files are updated in place: other entries, tables and comments survive, permissions are preserved, and the replacement is atomic.

gori ca

gori ca
gori ca --pem
gori ca --ca-dir=DIR
gori ca regenerate
gori ca regenerate --yes
gori ca import --cert root.crt.pem --key root.key.pem --yes

Prints the path to gori's root CA certificate (creates it on first use). Use this when trusting the CA in a browser or system store, or when pointing a client at --cacert.

A verb comes first and its flags after it: gori ca regenerate --ca-dir=DIR, not gori ca --ca-dir=DIR regenerate. The reverse order is a usage error, because the verb would otherwise be dropped and the command would print the CA path as if it had done the work. None of the three forms takes a positional argument.

gori ca also reports a root CA that loads but cannot serve (a private key that does not match the certificate, or a key gori cannot sign with) on stderr, since the symptom otherwise appears only at the client as an "unknown CA" or "bad signature" handshake failure. regenerate and import are the fix, and both work on a CA directory in any state, including one where only one file of the pair survives.

gori ca regenerate

Replaces the on-disk root CA with a freshly minted one. Destructive: every client that trusted the old CA must re-trust the new certificate. Any already-running gori process keeps the old CA in memory until restarted.

Without --yes, the command prompts on a tty and expects you to type regenerate (same word as the TUI confirm). Scripts and CI should pass --yes. On success the new cert path is printed to stdout.

gori ca import

Adopts an externally-created root CA (a certificate + matching private key, both PEM) in place of gori's own, for sharing one CA across a team or machines, or reusing an organization CA. gori needs both files because it signs per-host leaf certificates on the fly; clients trust only the certificate. Destructive, like regenerate: it replaces the on-disk root and voids prior trust.

The pair is validated before anything is written: the key must match the certificate, the certificate must be a CA (basicConstraints CA:TRUE), and gori must be able to sign a leaf certificate with the key. That last check rules out Ed25519 and Ed448 roots, because gori signs leaves with SHA-256, which those keys do not support. Use an EC P-256 or an RSA root. A rejected pair aborts without touching the current CA. An expired or not-yet-valid certificate imports with a warning. Confirm by typing import on a tty, or pass --yes. The same action is available from the TUI palette (Import CA certificate).

Generate a root with OpenSSL, then import it:

openssl ecparam -genkey -name prime256v1 -out root.key.pem
openssl req -x509 -new -key root.key.pem -days 3650 -subj "/CN=my ca" -out root.crt.pem
gori ca import --cert root.crt.pem --key root.key.pem --yes

Trust only root.crt.pem in your clients. Never distribute the private key.

gori settings

gori settings                      # print the settings.json path
gori settings --edit               # open it in $EDITOR
gori settings sections             # list the top-level sections
gori settings export [-o FILE]     # write a shareable profile (stdout by default)
gori settings import FILE          # apply a profile's sections
gori settings tls-fingerprint      # the JA3/JA4 gori sends to each destination
gori settings env-syntax [VALUE]   # read or set the env-token grammar
gori settings user-agents          # the list $GEN.USER_AGENT draws from

gori settings env-syntax

Which grammar spells an env token: namespaced ($ENV.KEY for env vars, $BIND.NAME for session bindings, $GEN.NAME for per-request generators) or bare ($KEY, $NAME, with no generator spelling). A global setting, because it decides how the tokens in every project are read. With no argument it prints the value in force and where it came from.

gori settings env-syntax
# namespaced  (from /Users/me/.gori/settings.json)
#   $ENV.KEY / $BIND.NAME / $GEN.UUID

gori settings env-syntax bare
# env syntax: bare — $KEY / $NAME
# Each project is re-spelled the next time it opens: its stored tokens are rewritten from
# namespaced to bare, a backup is written beside the database, and the run that does it says
# so. Captured evidence is left exactly as it was. Switch back with `gori settings env-syntax namespaced`.

Namespaced is the grammar for everyone, so the absence of env.syntax in settings.json means the file predates namespaces: the next start adopts namespaced, re-spells the global rewrite rules (keeping a settings.json.pre-namespaced-<timestamp> copy) and writes the key. Each project is re-spelled the first time it opens after the grammar moved (in the TUI, in any gori run …, or in a gori mcp server), with a gori.db.pre-<grammar>-<timestamp> backup beside the database (VACUUM INTO, so the WAL is included) and one line per project on stderr saying how many tokens moved. Rewritten: Repeater drafts (request, target, SNI, name) and their WebSocket messages, Fuzzer templates, Miner and Sequencer requests, rewrite-rule replacements, session-slot header values, and the masked tokens in issue titles/notes and note bodies. Left alone: every row whose provenance is a capture (flow_id set; a capture expands nothing), any row the target grammar has no equivalent spelling for, and names that are table keys rather than tokens (env vars, extract rules, rule patterns, payload sets).

env.syntax = bare is the opt-out and re-spells each project back on its next open, escaping a literal $NAME that would otherwise start resolving. See Environment Variables. gori settings import says on stderr when a profile's env.syntax differs from this install's: an import never changes the grammar.

gori settings user-agents

The list $GEN.USER_AGENT draws from. With no flag it prints the list in use under a # line naming its source. --set reads that same format back, so you can save the output, edit it, and set it again. --set replaces the built-in list with the file's lines, one User-Agent per line, with blank and # lines skipped. A line gori cannot put in a header refuses the whole file and changes nothing. --reset goes back to the built-in list.

gori settings user-agents > ua.txt       # the list in use
gori settings user-agents --set ua.txt   # replace the built-in list
generator | gori settings user-agents --set -
gori settings user-agents --reset        # back to the built-in list

Stored as user_agents in settings.json, and editable in the TUI from Preferences → Editor & Keys → User-Agents.

Profiles

export and import move settings between machines, share them with a team, or check a configuration into a repository for a reproducible run. The unit is the top-level section, listed by gori settings sections.

gori settings export --sections network,scan_rules -o team-profile.json
gori settings import team-profile.json --dry-run     # show what would be applied
gori settings import team-profile.json --sections network

gori settings sections lists every section gori knows, marking the ones this install has no value for yet:

…
statusline  (can carry commands)
…
network
…
editor  (can carry commands)
…
env  (holds secrets — excluded unless named; not set — at its default)
scan_rules  (can carry commands; not set — at its default)
…
decoder  (holds secrets — excluded unless named; can carry commands; not set — at its default)
rewriter  (can carry commands)
…

A section marked not set is still a valid name for --sections: exporting it simply carries nothing (gori says so on stderr), and importing one writes it for the first time.

A section you do not select, or that the profile does not carry, is left exactly as it was. That is the guarantee --sections is choosing between. Within a section the profile does carry:

• List and table sections replace wholesale: upstream_rules, outbound_tls, listeners, scan_rules, hostname_overrides, tabs, and the rest. A profile carrying "upstream_rules": [] clears the table; that is how "no rules" is stated.
• Object-of-scalars sections apply key by key: network, editor, probe. A key the profile omits keeps its current value, so a team profile that pins network.upstream_proxy does not also reset everyone's bind_port to a default it never mentioned.

Note that export omits a section sitting at its factory default, so a profile is a set of values to apply, not a snapshot of a whole configuration: exporting from a machine where a value is default will not reset that value on a machine where it is not. Pass --dry-run to see which sections an import would touch. It errs on the side of listing one, so a section it does not name is guaranteed to be a no-op.

Import goes through the same writer the TUI uses, so it keeps the atomic write and cannot clobber a concurrently-running gori's edit to, or deletion of, a section it did not touch. Unrecognised sections in the file are reported and ignored: they reach neither the live settings nor the file.

If gori cannot load your settings.json (unparseable, unreadable, or a --config pointing at something it cannot open), both export and import refuse rather than proceeding. Every section is at its factory default at that point, so an import would persist those defaults over every section the profile does not name, and an export would write them out as if they were yours. Fix or remove the file first; an unparseable one is kept alongside it as settings.json.corrupt. --dry-run is the exception: it writes nothing, so it still runs, and says on stderr that the comparison is against defaults.

env, decoder and oast_providers are excluded from an export by default: env holds token values, decoder holds your saved chain library (open sub-tabs live in the project store, not here), and oast_providers holds self-hosted interactsh tokens. Naming one explicitly (--sections env) is how you consent to include it. Note that upstream_rules is safe to share: it stores a username and an environment-variable name, never a password.

A profile never carries, and an import never changes, the values that decide how this install's existing data is read: the token grammar (env.syntax), the token prefix (env.prefix) and the redaction salt (redaction.salt). An import keeps the local values, and says on stderr when the profile's grammar or prefix differed. Imported global rewriter rules, colormarker rules and saved views are numbered from this install's own counters, so a project's override of a deleted local rule never attaches to an imported one.

-o pointing at your live settings.json is refused. An export is not a snapshot (it omits every section at its factory default, and omits env, decoder and oast_providers unless you name them), so writing one back over the real file would delete those sections rather than update it.

When an export does carry one of those sections, -o FILE is created 0600 and gori says so, naming what is in the file. Consenting to export a credential is not consenting to leave it world-readable. An ordinary export stays 0644, and an export that names env on an install with no env vars is an ordinary export. The mode follows what the document actually contains, not what you typed.

Profiles that carry commands

Five sections can hold a command rather than data. They export like any other setting, because a team standardising on one re-signing hook is what hooks are for. Both ends say what is in the file.

The first three are process hooks. statusline is the sharpest of the five: it is a full shell rather than an argv exec, it carries its own enabled in the same section so a profile arms it outright, and it fires on a timer with no traffic needed. An editor command is only reported when the profile sets one; an empty value means gori falls through to your own $VISUAL/$EDITOR/vi.

Two more shapes run no command but are listed and gated the same way, as env and file rows: an upstream_rules entry with a password_env (gori reads that variable on your machine and sends it to the proxy the profile names), and a rewriter short-circuit with a body_file (it serves a local file, or with respond: dir a directory, to pages on the matched host).

export counts them on stderr, leaving the profile on stdout clean:

note: 5 entries in this profile run a local command (2 rewriter pipe, 1 scan_rules exec, 1 statusline sh -c, 1 editor exec) — whoever imports it runs them with their own privileges

import lists them one per line, argv included, and refuses to write until you acknowledge them. --dry-run prints the same list and writes nothing either way:

$ gori settings import team-profile.json
5 entries in this profile run a local command here, with your privileges:
  rewriter pipe     resign body    ./resign.sh --key $TOKEN
  rewriter pipe     (unnamed)      /usr/local/bin/hmac  [disabled]
  scan_rules exec   leak detector  ./detect.py
  statusline sh -c  command        gori-status --project
  editor exec       command        nvim
importing them is the same trust decision as running the author's script
gori settings import: refused — the 5 entries listed above run a local command with your privileges. Read them, then pass --allow-commands. Nothing was written.

Read the commands, then pass --allow-commands. There is no interactive prompt, so a scripted import stays scriptable; the flag is the acknowledgement. An entry the profile carries but leaves off is marked [disabled]: it runs nothing until someone arms it, and it is still in the file. Narrowing with --sections narrows this too: an import that applies only network arms nothing, so it neither lists an entry nor asks for the flag.

gori settings tls-fingerprint

Prints the JA3 and JA4 fingerprint of the ClientHello gori actually sends, per destination: the offer an anti-bot stack (Cloudflare, Akamai, DataDome, PerimeterX) reads before it decides whether to challenge you. It is the check for the outbound_tls fingerprint fields: OpenSSL will only ever tell you what got negotiated, never what was offered, so without this the settings are unverifiable.

gori settings tls-fingerprint                    # every rule, plus the no-rule default
gori settings tls-fingerprint shop.example.com   # the one policy that host would get
gori settings tls-fingerprint --json             # machine-readable, with the raw lists

# …and what a PER-SEND override would send instead, the same narrowing a Repeater tab's
# ␣Pt or a `--tls-preset` run applies, without touching settings.json:
gori settings tls-fingerprint shop.example.com --preset curl

shop.example.com  (matched rule "shop.example.com")
  preset          chrome
  groups          X25519:P-256:P-384
  …
  tunnelled (gori offers h2) — ALPN h2, http/1.1
    JA3  c99e92e692ba483e2602b38b3c0a5645
         771,4865-4866-…,65281-0-11-10-35-5-16-22-13-43-45-51-21,29-23-24,0
    JA4  t13d1513h2_8daaf6152771_afafd945c4ab
         t13d1513h2_002f,0035,…_0005,000a,…_0403,0804,…

Each policy is reported for two legs, and the difference between them is real. gori offers h2 on a decrypted MITM connection; on a leg it is going to speak HTTP/1.1 on (the forward-proxy dial, the Repeater, WebSocket) it drops h2 from the offer, and with no alpn configured it sends no ALPN extension at all, so those legs carry different ClientHellos. The second line under each digest is the list it hashes: that is where you see which field a setting moved, and it is the half worth comparing against a browser.

The context the report reads is the same one a dial builds, so it cannot describe a handshake gori does not make. A groups or sigalgs string this OpenSSL rejects is reported on stderr for that rule and the rest still print.

--preset NAME narrows every reported policy the way a per-send override does (see Per-send TLS fingerprints), so you can check what --tls-preset curl will actually put on the wire for a host that already has a chrome rule. The client certificate, protocol range and permissive flag stay the destination's; only the ClientHello shape is replaced. An unknown name is refused rather than reported as an empty hello.

Per-send TLS fingerprints

outbound_tls is keyed by destination host, which is right for a standing policy and wrong for the question the fingerprints exist to answer: does this endpoint answer differently as chrome than as curl? That is an A/B on one host, and doing it by editing a global rule between two sends makes the two sends incomparable, and changes the handshake for every other tab and background capture hitting that host at the same time.

A per-send override names a preset for one send or one run, resolved at dial time, without touching the destination table:

gori run repeater 42 --tls-preset chrome           # replay a captured flow as Chrome
gori run repeater 42 --tls-preset curl             # …and again as curl, comparably
gori run repeater send 7 --tls-preset firefox      # override a saved session for one send
gori run repeater create --tls-preset chrome …     # store it on the session
gori run fuzz --flow 42 --auto --tls-preset chrome # the whole sweep, one handshake

In the TUI it is ␣Pt on a Repeater tab (a ␣Pt:… chip on the TARGET band), persisted with the tab so a reopened one sends what it sent before, and the Fuzzer's TLS fingerprint row on the ^O advanced card. Over MCP it is send_request{tls_preset} and fuzz_start{tls_preset}, both echoed back so a result set says which handshake produced it.

The override narrows the destination policy rather than replacing it:

Two sends differing only in the override dial two separate SSL contexts, so they really are two handshakes. https only: a plaintext leg sends no ClientHello, and gori will not report one it did not send. As with the destination-level presets, these are approximations (extension order and GREASE placement are OpenSSL's), so check one with gori settings tls-fingerprint HOST --preset NAME rather than assuming it.

--config PATH

--config points gori at a specific settings file for one run. It works before any subcommand:

gori --config ./ci-profile.json run capture --for 5m
gori --config ~/profiles/corp.json          # the TUI, with a different config

Resolution order is --config → $GORI_CONFIG → $GORI_HOME/settings.json.

This is deliberately orthogonal to GORI_HOME: it changes only which settings file is read and written, leaving the CA, the project databases, the themes and the wordlists where they are.

gori wizard

gori wizard

Runs the interactive setup (global proxy bind default, then theme, then the Miss Ring mascot, then a review that also names your editor keyset and where to change it). Also runs automatically on first launch. The bind step writes the shared settings.json defaults and warns when something already listens on the chosen port (press Enter again to keep it anyway). Projects can still pin their own address in the Project tab; --listen / --port override for one run only. Esc twice skips the wizard; the rows are also clickable.

gori tutorial

gori tutorial

Interactive tour of the TUI on a mock UI: tab/pane navigation (including a sub-tab strip), the space menu (Space) and its second cards, the command palette's search (Ctrl-P), READ/INS edit mode, where to point a client and how to trust the CA, the capture switch, intercept (i outside an editor), and Help and quitting. The mock menus and every key the tour names read from your install. Each lesson demos the move and prompts you to try it, and its step on the rail turns ✓ only once the whole move is done (◐ marks a step you only visited); practice has six optional checks across the first four moves. The last card guides you from the screen you return to: picker, a --db project (with picker fallback), shell, or current session; finishing a standalone gori tutorial prints the next command to run. Offered at the end of gori wizard, and available inside a session as the palette command Guided tour (Ctrl-P); safe to re-run anytime without a live proxy session. See the Quick Start and Space Menu & Palette.

gori update

gori update
gori update --exec   # Homebrew/Snap: run the package-manager command

Detects how this gori binary was installed and updates accordingly:

A store path is /nix/store/…, and also a relocated store: a rootless install keeps one under ~/.local/share/nix/root, and NIX_STORE_DIR moves it anywhere. Off the default prefix it is the store-hash shape that identifies one, so a directory you happen to have called nix/store is still an ordinary binary install.

Paths under /usr/bin or /bin are classified by package ownership (pacman -Qo, dpkg-query -S, rpm -qf). If a manager owns the file, gori never overwrites it. If probes find no owner, the binary channel self-updates. When no package tools are available, /etc/os-release (ID / ID_LIKE) picks Arch-like / Debian-like / RHEL-like guidance as a fallback.

Release asset names match the installation guide (gori-v*-linux-* plain binaries, gori-v*-osx-*.tar.gz archives). macOS archive updates require a dedicated layout (e.g. PREFIX/opt/gori from the curl installer) so bundled lib/ is never written under shared roots like /usr/local/lib. If no release assets exist yet, the command exits with a clear error pointing at the releases page. It does not silently no-op.