Remote access & MCP

borg mcp lets an AI agent such as Claude work in the borg you have open, either on your own machine or on a server you reach over SSH. You do not need to install anything besides borg: the agent starts borg mcp itself (through SSH for a server), and it connects to the borg session running there. The server needs no open ports and no internet access.

Connecting Claude

Press F1 and then C (or choose F9 → Remote → Share this Borg as host…). Borg shows two commands to paste into a terminal on your computer: one starts Claude Code already connected to this borg, the other adds the connection to Claude Code for every session. Tab chooses one, and Enter copies it to your computer’s clipboard through the terminal. That works over SSH in iTerm2, Ghostty, kitty, WezTerm, and Alacritty (in tmux, add set -g set-clipboard on). Where the terminal does not accept it, as in many browser terminals, F3 shows the command on its own as plain text so you can select it with the mouse; any key returns to borg.

Over SSH, borg fills in the address you connected to. If your computer reaches the server under another name, such as an SSH alias or through a jump host, type that name instead. SSH must log in without asking for a password, using a key or an SSH agent. borg mcp setup prod prints the same setup for Claude Code and Claude Desktop from the command line.

What the agent can do

Once connected, the agent sees what you see: the screen itself as text, whether you are in the panels or the console, both panels, the highlighted and marked files, where the command line runs, and what is typed on it. It refers to places as locations: an absolute path or ~/… on the machine borg runs on, docker://web/etc/nginx inside a container, or a path relative to the active panel. Without asking, it can read folders and files (by line range, or only the lines that contain some text), see the busiest processes and the containers, and show a file or folder in your other panel. It can also list the open ports, the connections, and the network interfaces with their traffic, measured over one second and narrowed with the same words as the network screen’s filter (see Filtering). It can list the startup items too, newest change first, with their programs and the rules they matched, narrowed with the same words as that screen’s filter (see Startup items).

Anything that changes the machine waits for you in a dialog that shows the whole change: a command and where it will run, a new file, or an edit as a diff. Scroll long ones with the arrow keys, PgUp and PgDn, or the mouse wheel, and press F3 to see the dialog full screen. No stays selected until you choose Yes, and the dialog ignores Yes for its first half second, so a key or click meant for something else cannot approve it. An edit is refused if the file changed while you were deciding. A command with tabs, escapes or other control characters is refused too, since the dialog cannot show them. The dialog shows on top of everything, including the editor, the viewer, another dialog and the screensaver, and it takes every key until you answer. What it covered comes back afterward. If the agent stops waiting first, the dialog closes and a notice says so. For a paired computer, approval_mode asks you once before turning on Approve all for that session. While it is on, a badge stays visible; click it or press Ctrl+Alt+A to turn it off at once. It also turns off when that paired connection closes. Pairing approvals are separate.

A request also reaches your own computer when a remote panel there shows the session it waits in (see Remote panels). Your borg shows it in the same dialog, titled with the server’s name, over whatever you are doing, and sends your answer back over the encrypted connection. The server keeps its own dialog open too. The first answer counts, wherever it comes from, and the other dialogs close with a notice that says where it was answered. A request the agent withdraws closes everywhere. When another computer controls the session through a mirror, your dialog shows the request without Yes and No, and Esc closes it on your screen only. While that session approves everything, your borg shows a badge with the server’s name; click it or press Ctrl+Alt+A to turn Approve all off there at once. Only your keys and clicks answer these dialogs: the agent’s tools, type included, cannot press anything in them.

Commands are typed into a shell you can watch, and kept out of its history. Commands for this machine go into borg’s own console, which is shown while they run so you can answer a prompt such as sudo’s; commands for a container go into that container’s shell in the Docker view. The shell keeps its folder and variables between commands.

The agent can also type text for you to review: a command at the prompt, or a script into vim or nano open in the console. Nothing runs: Enter is never pressed, and text with several lines goes in as a paste, which shells and editors insert without running it.

The agent can also search a process’s memory the same way the memory search does, for strings, indicators, text, or bytes. Memory can hold passwords, keys, and private messages, and whatever the search finds goes to the agent, so the first search of each process waits for your approval in a dialog that names the process, its program, and the search. Once you approve, the agent can search and scan that process again until borg quits. It can ask to read as administrator, which opens the system’s own password prompt.

The agent can also scan with YARA rules and check code integrity, as Rule matches in the Ctrl-F dialog and Y and I in the memory map do (see Scanning files with rules, Code integrity check and Scanning memory with rules). A file or folder on the machine borg runs on is scanned without asking, the same as a read. A folder scan reads every file below the folder on the same file system, hidden files included. It leaves files over 64 MiB unread and stops after 20,000 files, 2,000 matches or 45 seconds. Files in containers are not scanned.

A process is different, because the scan reads its memory. The first scan of each process waits for you in Remote wants to scan process memory, which names the process, its program and the checks: the integrity check, the rules, or both. One approval covers scans and memory searches of that process until borg quits, whichever the agent asked for first. Each check stops after 45 seconds, 1 GiB of memory or 2,000 findings. The agent can ask to read as administrator, which opens the system’s own password prompt once for both checks.

The rules are Borg’s and those in your rules folder, unless the agent brings its own rule text of up to 64 KiB. That way it can draft a rule from what it found, try it on a folder or a process, and refine it. Its text runs alone, without Borg’s rules or yours, cannot use include, and is never saved. Text that does not compile goes back to the agent with the compiler’s message, before any dialog. For a process, the dialog shows the agent’s rule text below the checks, so you see what it looks for.

The agent gets each finding, worst first, with its severity, its kind, the rule and where it comes from, the file and offset or the address and memory region, up to 64 bytes of what matched as text or hex, and what else could explain it. Then come how much was read, what could not be read, whether the scan finished, and the rule files left out. Evidence goes to the agent as found, keys and tokens included, as with the memory search.

The agent can also capture traffic as R does on the network screen (see Capturing traffic). It names what to record: a port, one connection, a process by its PID, or all traffic on the interface. For a process, Borg records the whole interface and sums up that process’s conversations. A capture lasts 1 to 60 seconds, 5 unless the agent names a length. When the agent names no interface, Borg measures for a second and picks the one the Capture traffic dialog would. Each capture waits for you in a dialog, Remote wants to capture traffic, that shows the traffic, the interface, the duration, how much of each packet to keep, and the folder. While it runs, the footer shows it, and a notice then says where Borg saved it: in the active panel’s folder or one the agent names, readable only by you. An agent’s capture always runs as you and never asks for an administrator’s password, so without access it ends with No permission to capture on and the interface’s name.

The agent gets back a summary: the protocols Borg recognized, then each process, host and connection with its packets and bytes, with host names from the capture’s own DNS answers and TLS server names. Borg watches the sockets while the capture runs, so conversations belong to their processes even with the network screen closed. The summary leaves out what the packets carry. Reading a .pcap, .pcapng or .cap file gives the same summary, narrowed with the words of the traffic viewer’s filter, and the agent can ask for one packet by its number to get its layers and its bytes as a hex dump. Borg remembers the processes of its last 16 agent captures until it quits. Other files show their conversations under Unknown process, unless their packets carry their process.

While an agent is connected, ◈ Remote appears at the start of the shortcut bar. Click it, or choose F9 → Remote → Remote log… at any time, to see a log of what the agent did: what it looked at, read, scanned, showed, and typed, and every command and change, approved or declined. Each session keeps its log on disk, readable only by you, so you can come back to a session you left running and see what happened there, even after Borg quit. When the log grows large, Borg drops the oldest entries. Before an entry is saved, Borg hides the passwords, tokens and keys it recognizes, and it leaves out what commands printed. A password passed as a plain word looks like any other word, so Borg cannot hide it. To keep no log at all, turn off Remote: keep a log of what it does in Options → Plugins, which also deletes the saved log.

Borg cloud

Borg cloud lets Claude reach a borg it has no SSH route to: a server you open in a browser terminal, a container, or a machine behind NAT. Both sides connect out to a relay, and the relay joins them.

1. In borg on the server, press F1 then C. The first option is borg pair with a link; Enter copies it. The link works once, for ten minutes. Below it is the relay: to use a different relay, paste its address there and press Enter to save it and get a link through it.
2. Run the command in a terminal on your computer, where borg is installed too. It prints a pairing code: six emoji, each with its name, such as 🐱 Cat · 🦁 Lion · 🐎 Horse.
3. Borg on the server asks whether to pair, showing your computer’s name and the code. The question comes up at once, even while F3 shows the command as plain text. Choose Yes if the codes match. borg pair then offers to add the server to Claude Code, as claude mcp add borg-NAME -- borg mcp remote NAME. It waits 5 minutes for your answer; when it gives up or you stop it, the question closes and the link stops working.

The code comes from the encrypted handshake the two borgs have just completed, so it is the same on both screens only if your computer is the one talking to the server. Someone who got hold of the link and used it first would show the server a different code, and cannot choose one that matches yours. If your terminal draws emoji narrower than borg expects, borg shows only the names; compare the names instead.

From then on, Claude can reach that borg whenever it is running there. borg pair on its own lists the paired servers, and borg pair --forget NAME forgets one; on the server, F8 in the Remote access dialog forgets every paired computer. Through borg cloud, Claude also gets download and upload, which copy files between the server and your computer; borg get NAME:PATH [TO] and borg put FROM NAME:PATH do the same from your terminal. Claude’s downloads go into your Downloads folder and never replace a file there. Uploads wait for your approval in borg, which shows the file being sent, and every approval names the computer that asked.

The connection is encrypted end to end. Every borg keeps a server key, which paired computers know it by, and a computer that reaches servers also keeps a computer key of its own. Both are readable only by you. The server key is a file in the link folder of the state folder. The computer key is a file there too. On a Mac it lives in your login keychain instead, and on Linux the file is sealed with a password (see Computer keys). Pairing exchanges the public keys, and every connection opens with a Noise IK handshake bound to them, so the relay only ever forwards ciphertext and cannot answer in either borg’s name. Calls from another computer can read without asking, just like local ones; turn on “ask before another computer reads” in Options → Plugins to make those reads wait for approval too. Borg keeps no connection to the relay unless it is paired or showing a pairing link, and none at all when borg cloud is turned off in Options → Plugins.

Borg saves the relay in the config as relay = "wss://relay.example.com". A computer reaches the server through the relay it paired through, so after the server switches relays, pair the computer again. All borgs on one machine share their keys, and the background service connects them all to the relay. With the service turned off, only the first borg opened connects, and the others tell you which one has borg cloud.

Computer keys

The computer key proves to each paired server that a connection comes from your computer. When a server still knows this computer by another key, such as this machine’s server key, Borg moves it to the computer key the next time it opens a session there. Borg proves to the server that it holds the new key, and the server swaps the key in that computer’s entry and keeps its name. Connections that still use the old key end at their next call. The server shows a notice and writes both fingerprints to the agent log, and its Clients list shows when the key changed and what it was. A server running an older Borg keeps the old key until it is updated.

On a Mac, Borg keeps the computer key in your login keychain, as an item named Borg Commander that only Borg may read without asking you. The first time a Borg process needs the key, macOS asks for Touch ID or your password, so even a program that starts borg on its own shows itself. After each Borg update, macOS also asks once whether the new Borg may use the item; choose Always Allow. A computer key file from an earlier Borg moves into the keychain the first time Borg uses it, and the file is deleted. A Borg that runs without the Mac’s screen, such as over SSH or in the background service, cannot show the prompt and cannot reach servers. When $BORG_STATE_DIR names a state folder other than the usual one, Borg keeps the computer key as a file in that folder’s link folder. Borg’s macOS releases are signed with the Hardened Runtime, so other programs cannot read Borg’s memory or load code into it.

On Linux, Borg seals the computer key with a password you choose, in the file computer-key.sealed in the link folder. Run borg unlock in a terminal to choose it: Borg suggests four random words, which are easy to type and hard to guess, and asks for the password twice. Borg stretches the password with Argon2id, which takes a few seconds and 1 GiB of memory, or an eighth of the memory on a machine with less than 8 GiB, so guessing it from a copy of the file is slow. A computer key file from an earlier Borg is sealed the first time you run borg unlock, and the file is deleted; until then, Borg asks you to run it. When $BORG_STATE_DIR names a state folder other than the usual one, Borg on Linux also keeps the computer key as a plain file, with no password.

Once unlocked, the key stays in your user’s kernel keyring until 12 hours pass without Borg using it, and every use starts the 12 hours again. A restart locks it, and borg lock locks it at once. Where Borg cannot use the kernel keyring, as in many containers and system services, a small Borg process holds the key instead, on a socket in the link folder that only you can open, and it ends after 12 hours without use. When the key is locked, Borg asks for the password: the panels open the Unlock key dialog, and borg pair, borg get, borg put and borg mirror ask in the terminal. borg mcp remote, which Claude starts without a terminal, says to run borg unlock.

borg unlock --ssh-agent also lets your ssh-agent unlock the key. Borg asks the agent to sign a fixed challenge with an Ed25519 key, or with an RSA key when it holds none, and seals the key a second time with that signature. From then on, Borg unlocks the key without asking while that agent is reachable, and the password keeps working. Borg checks that the agent signs the same way twice, and refuses a key whose signatures change. Anyone who can use your agent can make the same signature: when you forward it with ssh -A, root on the far machine can use it while you are connected, and with a copy of the sealed file could unlock this key. Forward the agent only to machines you trust, or leave this off. borg unlock --no-ssh-agent turns it off again.

borg pair --new-key gives this computer a new key, and each server takes it the next time Borg connects to it. Until every server has, Borg keeps the old key too, and borg pair marks each server that still takes it. A week later it also suggests forgetting servers you no longer use, with borg pair --forget NAME.

When a server refuses every key this computer holds, Borg says so. Either someone forgot this computer on that server, or someone with a copy of its key moved the server to a key of their own first. A new key is hygiene and does not undo a leak. If you think someone copied a key, press F8 in Remote access on every server to forget the paired computers, pair again, and check those servers.

Named sessions and the background service

With named workspaces, borg sessions list shows their IDs and names, borg sessions create NAME adds one, and borg --session NAME opens it. Over MCP, the agent can call list_sessions, list_remote_sessions, and use_session to choose which session that connection works with. A single tool call can also pass a session ID to target another session just once. The chosen session applies only to that MCP connection.

With more than one session, or when the only one is open in another terminal, borg starts with the Borg sessions window. Its first lines say what a session is, and the list shows each session with when it was last used. A session that is active right now is marked with its status: Open in another terminal, or Kept running by the service when the background service runs it. The session used last is chosen, unless another terminal has it open. Enter opens the chosen session where you left off; one the service keeps opens attached, as with borg service attach NAME. A click chooses a session and a second click opens it. F7 names a new session and opens it, and Esc or F10 quits without opening one. While the window is open, it checks every 2 seconds which sessions are active.

F8 or Delete removes the chosen session after a confirmation that defaults to No. This deletes its saved panels and terminal history; your files and folders are kept. The Default session always stays, and so does a session that is active right now: quit Borg in the other terminal first. To remove a session the service keeps, open it with borg service attach NAME and quit with F10.

When you name a session with borg --session NAME that another Borg has open in a terminal, borg stops and names that Borg: its process number, its terminal as ps shows it, and how long ago it started. Quit that Borg with F10 where it runs. When you can no longer reach its terminal, end it with kill and the process number.

All your Borgs on a machine share one background service. The first borg you open starts it, with nothing to install, and it stops 30 seconds after the last session closes. To turn this off, set start-service = false in the config.

The service keeps borg cloud connected for all your Borgs, so a paired computer reaches every open session. It works in the session it names, or in the one you used last, and waits for your approval there. You can pair from any Borg.

To keep a session running with no terminal, run borg service keep NAME. Open it with borg service attach NAME or from the Borg sessions window, and press Ctrl-] to detach. Quitting Borg there with F10 ends the session. When a paired computer asks for a session that is not running, the service starts it in the background.

To start the service at boot, run borg service install, enable, and start. They use sudo, which asks for your password, unless you are root. borg service stop, disable, and uninstall undo them. You can also choose F9 → Remote → Background service…: the dialog shows the command for the next step, and Enter runs it in Borg’s shell. In a container without systemd, have the container’s process supervisor run borg service run.

Updating with sessions open

borg update installs the new version, then moves the background service to it and tells you once the service runs it. The service starts again in its own process, so the sessions it keeps hold on to their shells and the programs running in them. Every open Borg follows when it is idle: it waits for running jobs to finish, for edited files to be saved or closed, and for an agent’s request to be done. Then it starts again in the same terminal, keeps its shell, and says which version it runs now.

The update keeps the version it replaced next to the program file, as .borg.previous. When the new version does not take over within 60 seconds, Borg puts the previous one back and the service starts again on it. The sessions it kept then start with new shells.

A service started by an older Borg cannot move by itself. borg update says so, and the service uses the new version the next time it starts.

To update a paired machine, select it in Remote hosts and press U. After you confirm, the host gets the latest release the way borg update does, and its service moves to it. Esc closes the picker while the update goes on. Borg then tells you which version the host runs, or that the new version did not start and the host went back to the one it ran. A mirror of one of its sessions waits for it and shows the host again once it is back (see Mirroring a session). Run borg update on the host instead when its Borg is older or runs without the background service. Borg installed there with Homebrew or cargo is updated with that tool on the host, and Borg names the command.

Remote panels

After pairing, borg --remote MACHINE:SESSION opens that session’s files in the left panel. Enter or F3 previews a remote file by downloading a temporary local copy. F5 copies marked files and folders between local and remote panels, or between two paired hosts, and the destination dialog says which client or host each side is. Copies run as background jobs with byte progress, pause and cancel, and a choice to overwrite, skip, or keep both. Folders are copied with their empty subfolders and symlinks, and regular files keep their executable permission and modification time. A file only appears at its destination once all of its contents have arrived. F6 (move) and F8 (delete) are not available in remote panels.

The right panel stays on your computer. With Options → Plugins → Follow turned on, the command line and Ctrl-O use an interactive shell on the remote host. Its terminal is drawn locally, while keys, pastes, Ctrl-C, and terminal programs run on the remote host. Each remote session keeps its own shell and unfinished command line while you switch panels, and selecting a client panel brings back the local shell.

Full-screen programs, and programs that read raw keyboard input such as top, receive every key while they run, Ctrl-O included, and resizing the terminal resizes the remote PTY. Quit such a program with its own keys (q in top). If you started it from the panel command line, Borg then returns to the panels; if you started it in the remote console, the console stays open. The remote Borg’s own panels and shell are separate from this console. To transfer files from the command line, use borg get MACHINE/SESSION:PATH [TO] and borg put FROM MACHINE/SESSION:PATH.

Typing exit in Borg’s main Bash, Zsh, or Fish shell asks for confirmation. No is selected by default and keeps the same shell, variables, folder, and mirrors running. In a remote console, exit asks whether to close the shell on the host; after Yes, choose the session again with Alt-H to get a new one.

Remote folders load in chunks, with a spinner and a count of the entries received so far; moving to another folder cancels the request.

While a remote panel shows a session, the agent requests that wait there show on your screen too, and you can answer them here (see What the agent can do).

Remote hosts

In local Borg, press Alt-H, click Remote hosts in the shortcut bar, or choose F9 → Remote → Browse hosts and sessions… to see paired machines and their named sessions. Enter opens the selected session’s files in the panel you opened the picker from, replacing what that panel showed. Press M to mirror the session’s screen, U to update the host (see Updating with sessions open), and R to refresh the list.

Tab switches between Hosts (computers this Borg can reach) and Clients (computers that can reach this Borg). Clients lists the computers paired with this Borg, their public-key fingerprints, whether they are connected, and how many connections each has. After a computer changed its key, the fingerprint line also says on which day, and the fingerprint it had before. A computer is listed once even when a mirror uses several connections. Status updates while the picker is open, including in a session whose connections are held by the background service. Pairing works in one direction only: an allowed client does not automatically become a host whose files this Borg can browse. When the connection owner cannot report connection status, paired clients are still listed, with Connection status unavailable. The same Borg can be a host and a client at once. The Remote menu also offers Mirror mounted host, Share this Borg as host…, Remote log…, and Background service….

The picker shows each host’s Borg version. Selecting a session shows its OS and architecture, whether it runs as a background service or in a terminal, request latency, and relay address. Hosts are checked in parallel, so one unavailable host does not hold up the others. A host that cannot report its version shows version unavailable; the relay’s version is not the host’s. Keep Borg up to date on both computers: a host that lacks a remote feature shows a message asking you to upgrade.

While a mirror connects, the picker shows an animated status, and Esc cancels right away. Each connection step has 10 seconds, and the whole attempt has 30. If the attempt fails, the picker stays open and says which step failed; M tries the selected session again.

In the picker, F2 renames the selected host for every session on it, and Shift-F2 renames the selected session. These names are saved on this client and appear in the picker, panel titles, and console footer. Leave a name empty to go back to the original. The details still show the original host and session names. Names are tied to the paired host’s key and the session ID; command targets and names on the remote host do not change.

F8 on an unavailable host forgets its pairing on this client, and Shift-F8 forgets the selected host even when it is online. Confirmation defaults to No. Forgetting a host closes this client’s panels and consoles for it; the host’s sessions and files are kept, and so are this client’s identity and its other pairings. Pair again to reconnect.

F8 or Delete on a host session removes it, after a confirmation that defaults to No. This closes the session and its remote consoles and deletes its saved Borg panels and terminal history; files and folders on the host are kept. The Default session cannot be removed. A standalone session that is currently hosting the connection cannot remove itself; first close it on the host and run Borg in another session. If removal fails, the session stays listed so you can try again. A running session is stopped first, and the service does not start it again.

Mirroring a session

borg mirror MACHINE:SESSION shows the remote session’s live screen in your local terminal; Alt+Shift+M opens the same mirror from a local Borg with a remote panel. Ctrl-G (hold Control and press G) leaves the mirror and returns to the local panels, as does a click on the banner at the bottom. The line above it shows who has control; Ctrl-] also exits.

A regular borg or borg --session NAME can be mirrored while it runs, without the background service. Its own terminal stays visible, and any keyboard or mouse input there takes control back from the mirror. While you have control, Borg on the host lays out for your window: when the space above the banner is smaller than the host’s terminal, Borg draws in the top left of that terminal at your size, and the rest of it stays blank. Once control goes back to the host’s terminal or you leave the mirror, Borg fills that terminal again. A mirror without control follows the host terminal’s layout and is cut off to fit a smaller window; making your window larger shows the rest. A session the background service keeps stays alive after its terminal closes, and the computer in control sets its size.

If another terminal has control of the remote session, the mirror opens in view-only mode and your keys do not reach the session. Press Ctrl-T or click the status line to take control and detach the other terminal, or start with borg mirror MACHINE:SESSION --take; --take always takes control from another viewer. Once you have control, the first key wakes a sleeping remote screen, and later keys and mouse input reach it. A viewer that falls behind skips old animation frames and jumps straight to the current screen.

When the host stops answering, for example while it updates, the mirror keeps the last screen, says so on its status line, and tries again every 2 seconds for up to 100 seconds. Ctrl-G leaves it meanwhile. Once the host is back, the mirror shows its screen again, with the version it runs now at the bottom right. A host that is still away after that ends the mirror with a message.

An agent’s request shows in the mirror as the server shows it, and you answer it there once you have control. If you opened the mirror from a remote panel and the request still waits when you leave the mirror, the panel’s borg shows it again.

Running a relay

borg-relay is the relay that borgs meet through. On a Linux server with a domain pointing at it and port 443 free, one command installs it as a service, with a TLS certificate from Let’s Encrypt:

curl -fsSL https://raw.githubusercontent.com/0xcd21h/borg-commander/main/scripts/install-relay.sh | sudo sh -s -- relay.example.com you@example.com

Run the same command again to update it.

On Dokploy, Coolify, or another Docker host whose proxy handles TLS, run the image ghcr.io/0xcd21h/borg-relay:latest and give it a domain on port 8080. In Dokploy, create an application from that Docker image with a domain on container port 8080 and HTTPS turned on; in Coolify, create a resource from that Docker image with port 8080 exposed and a domain. Both also accept packaging/relay/docker-compose.yml as a Compose service. The image runs borg-relay --behind-proxy: the proxy serves HTTPS and passes WebSockets through, and the relay applies its limits per client address as reported by the proxy in X-Forwarded-For. It runs as an unprivileged user and has a health check (GET /health).

On a Docker host without such a proxy, the same image serves TLS itself:

docker run -d --restart unless-stopped -p 443:443 -v borg-relay:/data ghcr.io/0xcd21h/borg-relay --domain relay.example.com --cache /data

Behind another proxy that handles TLS, run borg-relay --behind-proxy --listen 127.0.0.1:8080. Only run it this way behind a proxy, because the relay trusts the client address the proxy reports. The relay enforces limits per address on servers and sessions, frame size, bandwidth, bytes per session, idle time, and session length. It stores nothing except its certificate.

The relay logs only counts: once a minute, if anything changed, it writes a line such as

stats: connections=3 servers=2 sessions=1 joined=14 carried=3.2MiB limited=0

This shows the connections it holds, the servers registered, and the sessions open, and, since it started, the sessions joined, the bytes they carried, and the connections and sessions that a limit refused or ended. For debugging, --log, or the environment variable BORG_RELAY_LOG=1 for the image, also logs each server’s registration by the start of its key, each session with the bytes it carried, and each limit reached with the client’s address.