resterm

v1.17.2

Clipboard over SSH (OSC 52)

• With no clipboard tool on the host (usual over SSH), yank failed:

Clipboard unavailable; saved in editor register

• Now the copied text goes to your terminal with OSC 52:

Copied selection. Sent via OSC 52

• Editor yank, delete, change and response pane copy.
• Only when the clipboard tool fails.
• Works by default in Kitty, Ghostty, WezTerm, Alacritty, foot, Windows Terminal.
• iTerm2: Settings > General > Selection > "Applications in terminal may access clipboard".
• Not supported: macOS Terminal, GNOME Terminal.
• tmux: set -g set-clipboard on
• Paste unchanged. p uses the editor register, terminal paste in insert mode uses your clipboard.

Troubleshooting

osc52_limit

• Default 1 MiB, about 768 KB of text. Bigger copies stay in the editor register:

Too large for OSC 52 (limit 1 MiB). Saved in editor register

[clipboard]
osc52_limit = "8MiB"

• JSON: {"clipboard":{"osc52_limit":"8MiB"}}
• Raise it for Kitty. 16KiB for mosh.
• KB, KiB, MB, MiB, GB, GiB

Configuration

Broken settings file no longer overwritten

• A file that failed to load, for example diagnostics = 'yes', was replaced with defaults on the next theme change or layout save (g L).
• With settings.json, a new settings.toml was written and the JSON file was ignored after that.
• Now the save is refused and the status line shows why:

layout save error: settings not saved: parse settings "/home/you/.config/resterm/settings.toml": toml: cannot decode TOML string into struct field config.EditorSettings.Diagnostics of type *bool

• Fix the file and restart.

Mock server, recorder and OAuth

• :mock restart, :mock stop, the toggle key and quitting hung 3s:

Mock server stop failed: context deadline exceeded

• Stopping the recorder: same 3s, Recorder stopped: context deadline exceeded.
• OAuth auth code login: about 5s extra after "Authentication complete" in the browser.
• Cause: a connection that never sent a request (Go 1.27 clients, browsers). Resterm waited about 5s for it.
• Requests in progress still finish.

v1.17.1

Failed tests in the text report

The text report only gave a count for a failing request or step. 1.17.1 lists each failed test with its message, and workflow step details start under the step text instead of one or two columns to its left. A step with a failed JavaScript test in 1.17.0:

FAIL WORKFLOW check-user [0 passed, 1 failed, 0 skipped in 1.739666ms]
  1. FAIL Get [1 test(s) failed]
    Source Target: {{base.url}}/users/1
    Effective Target: http://localhost:3000/users/1

And in 1.17.1:

FAIL WORKFLOW check-user [0 passed, 1 failed, 0 skipped in 1.435875ms]
  1. FAIL Get [1 test(s) failed]
     Source Target: {{base.url}}/users/1
     Effective Target: http://localhost:3000/users/1
     Failed Tests:
       user has an email

• Passing tests are left out. A message over several lines stays lined up under its first line.
• With 10 or more steps, the step numbers are right-aligned so the details of every step start in the same column.
• This applies to -f text, to the default auto format whenever it prints the text report, and to the headless Text format.

JavaScript asserts show their text once

tests.assert and tests.fail used their text as both the test name and its message, so you saw it twice:

Tests:
  [PASS] status is 200
  [FAIL] user has an email - user has an email

Now it's [FAIL] user has an email. In JSON, failure.message is user has an email instead of user has an email: user has an email, and the failed test has no message field. client.test hasn't changed and still shows what failed it, as in user has an email - Error: no email for user 1.

--timeout stops JavaScript tests

@assert and RTS test blocks already stopped at the request timeout. JavaScript tests didn't, so a test stuck in a loop ran for 30 seconds whatever the timeout was. This one never moves to the next page:

### Orders
# @name Orders
# @script test
> {%
let page = response.json();
let count = 0;
while (page.next) {
  count += page.items.length;
}
tests.assert(count > 0, "has orders");
%}
GET {{base.url}}/orders

With --timeout 5s, 1.17.0 still waited 30 seconds and exited with 24:

Errors:
  Script error:
    error[timeout]: script exceeded the 30s time limit
    test script 1

1.17.1 stops it after 5 seconds and exits with 20:

Errors:
  Script error:
    error[timeout]: response checks timed out after 5s
    test script 1
    ╰─> context deadline exceeded

• All checks share one timeout that starts after captures. They run in order: @assert, RTS test blocks, then JavaScript tests. A check that hasn't started when the time runs out is skipped.
• @timeout on a request works the same way.
• A timeout in the checks exits with 20, like any other timeout. 1.17.0 exited with 24, the code for script errors, even when the error said timeout. A script that throws still exits with 24.
• A script block still stops after 30 seconds at most. Pre-request scripts don't use --timeout.

See exit codes.

Loop variables in step conditions

A step's @when or @skip-if is checked once, before the @for-each of the request it runs, so it can't read that loop's variable. For most names this fails with a hint. If the variable had the name of a built-in, such as list, json or len, the condition read the built-in instead and carried on without an error.

# @workflow sync-lists
# @skip-if list.archived
# @step Sync using=SyncList

### Sync list
# @name SyncList
# @for-each json.file("lists.json") as list
POST {{base.url}}/lists/{{= list.id }}/sync

old-promos is archived, and 1.17.0 synced it anyway:

PASS WORKFLOW sync-lists [3 passed, 0 failed, 0 skipped in 2.967291ms]
  1. PASS Sync (1/3) [200 OK in 1.218709ms]
    Source Target: {{base.url}}/lists/{

v1.17.0

gRPC requests can load their schema straight from .proto files, without server reflection or a compiled descriptor set. GraphQL subscriptions work over SSE and WebSocket.

gRPC with .proto files

Point @grpc-proto at your .proto files and Resterm compiles them when it sends the request, so there's no protoc step.

### Say Hello
# @grpc acme.v1.Greeter/SayHello
# @grpc-proto ./proto/acme/v1/greeter.proto
# @grpc-import-path ./proto
GRPC {{grpc.host}}

{"name": "Ada"}

Here greeter.proto imports acme/v1/types.proto from proto/. If a file doesn't compile, the error tells you where:

error[protocol]: compile proto files
╰─> acme/v1/types.proto:6:3
    ╰─> field acme.v1.Greeting.text: unknown type strng

• Without @grpc-import-path, the folder of each listed file is its import path. Add import paths when imports start from a root folder, as with protoc -I. Both directives can repeat, and paths can use {{variables}}.
• The standard google/protobuf/*.proto files are built in. Others, such as google/api/annotations.proto, have to be on an import path.
• Resterm reads the files on every send, so an edit to a .proto file applies to the next request without a restart.
• proto2, proto3 and edition 2023 files work. Edition 2024 isn't supported yet.
• A request can use @grpc-proto or @grpc-descriptor, but not both.
• The navigator lists the .proto files your requests use, and completion after @grpc-proto suggests only .proto files. Explain shows each proto file and import path.
• resterm collection export bundles the proto files together with every file they import.

See the proto files docs.

GraphQL subscriptions

@graphql works with @sse and @websocket. @operation, @query and @variables behave the same as over HTTP.

Over SSE

### Order events
# @graphql
# @operation OrderEvents
# @sse duration=30s idle=10s
# @assert stream.summary().reason == "complete"
POST {{graphql.endpoint}}

subscription OrderEvents($id: ID!) {
  orderEvents(id: $id) { status }
}

# @variables
{ "id": "{{order.id}}" }

The query is sent like any other GraphQL request, in the body for POST or as query parameters for GET. The stream ends at the first complete event and the summary reason is complete. If the server closes the stream before that, the reason is eof. This is the distinct connections mode of GraphQL over SSE.

Over WebSocket

### Order events over WebSocket
# @graphql
# @operation OrderEvents
# @query < ./queries/order-events.graphql
# @variables < ./queries/order-events.json
# @websocket
GET {{graphql.wsEndpoint}}
Authorization: Bearer {{token}}

Resterm uses the graphql-transport-ws subprotocol. It sends connection_init, waits for connection_ack, subscribes and answers each ping. When the operation ends with complete or error, Resterm closes the socket with code 1000. @ws steps run after the subscription starts, so # @ws wait 20s keeps listening for up to 20 seconds.

A GraphQL error doesn't fail the request, the same as over HTTP. Check for it with @assert. A message that breaks the protocol does fail it, with exit code 26. Here is the stream summary after a server sent a next message whose payload wasn't an object:

closeCode: 4400,
closeReason: "server sent next without an object payload",
closedBy: "error",
errorClass: "protocol",

• The request also fails if the server closes the socket before connection_ack (exit code 26), or if idle runs out before it arrives (exit code 20). After the ack, a close with any code, such as 4403, is a normal ending.
• Only graphql-transport-ws is supported, not the older subscriptions-transport-ws. On a @graphql request, any other subprotocols value is a parse error.
• connection_init has no payload, so send crede

v1.16.1

This release moves resterm to Go 1.27.3.

Important: Please update. This release blocks certificates from a compromised certificate authority (eMudhra).

Compromised eMudhra certificates

The private keys of eight intermediate certificates from the certificate authority eMudhra were so weak that anyone could recover them from the public certificates. With those keys, anyone can issue a valid HTTPS certificate for any website. eMudhra has revoked the certificates, and browsers and operating systems are blocking them. (CVE-2026-111943, Mozilla's write-up)

resterm 1.16.1 rejects any certificate chain through these intermediates on every platform. resterm 1.16.0 can still accept them on systems whose certificate store doesn't block them yet.

Before you update

macOS 12 Monterey is no longer supported. The macOS binaries need macOS 13 Ventura or newer. On macOS 12, do not run resterm --update, because it installs a binary your system does not support. Instead, build 1.16.1 with Go 1.26.10 or a newer 1.26 release, which has the same certificate fix:

go install github.com/unkn0wn-root/resterm/cmd/[email protected]

Some TLS-inspecting proxies may drop HTTPS connections. resterm now offers post-quantum (ML-DSA) signature algorithms when it opens a TLS connection. Some proxies and load balancers reset these connections. Reports so far name Palo Alto Prisma Access and F5 BIG-IP (golang/go#81199). If HTTPS requests fail with EOF or connection reset by peer after you update, build with Go 1.26.10.

Fixes

• An SSE stream that stops at its size or event limit now closes its connection right away instead of reading on in the background.
• Go security fixes for net/http, crypto/tls, net/textproto and html/template: CVE-2026-97031, CVE-2026-94440, CVE-2026-97032, CVE-2026-94439, CVE-2026-78663, CVE-2026-78669, CVE-2026-78660, CVE-2026-78667, CVE-2026-56866, CVE-2026-78659, CVE-2026-97030, CVE-2026-94448.

Other changes

• GODEBUG=tlsrsakex=1 and GODEBUG=tls3des=1 no longer turn RSA key exchange or 3DES back on for old servers.