Authorizing a Headless Linux Host

[outlyer]

I've been pretty impressed with OpenSave and I'm using it on my Mac and my PC. It's particularly useful for syncing Crossover (Wine on Mac) and my PC. However, I also have a headless Linux machine, and while I've searched the instructions posted, I am unable to figure out how to authorize a client that is headless.

I can load up the Linux host, and run opensave-cli daemon --start, and try to pair via my Mac or my PC.

Using the desktop app on my PC, I see the Linux host and click Pair and the daemon sees it, as shown in the logs:

2026-07-25T20:33:26Z [info] pairing request from "macbook-pro" (192.x.x.x) — awaiting approval

but in both cases, I cannot respond to the "Pairing Request" on the headless Linux host. In fact, I can't figure out how to interact with the Linux client locally at all. Running opensave-cli status in another window doesn't report anything.

I apologize if this is obvious and I'm completely missing something.

Thanks.

[farfromexact]

You are not missing a hidden CLI prompt. In the current Go rewrite, the headless CLI has commands such as status and daemon start, but no pairing-approval command. status only prints persisted paired peers; it does not print pending incoming handshakes.

The pending request is stored in the pairing manager and the approval operation is exposed by the local REST API:

GET  /api/peers
POST /api/peers/approve
body: {"peerId":"..."}

A practical headless workaround is to use an SSH tunnel to the Linux host, then query and approve through localhost:

ssh -L 8383:127.0.0.1:8383 user@linux-host
curl -s http://127.0.0.1:8383/api/peers
curl -X POST http://127.0.0.1:8383/api/peers/approve \
  -H 'Content-Type: application/json' \
  -d '{"peerId":"<value from pairingRequests>"}'

The API payload contains pairingRequests, including the peerId. This keeps the API local to the daemon; do not expose port 8383 to the public internet. The current source also documents the command as opensave daemon start rather than the older opensave-cli daemon --start spelling.

The relevant implementation is here:

• https://github.com/Liquid-co/OpenSave/blob/f2acdc9ef48ddb9ffff56a8707b1b5ba6bd47f5a/internal/api/routes_peers.go
• https://github.com/Liquid-co/OpenSave/blob/f2acdc9ef48ddb9ffff56a8707b1b5ba6bd47f5a/internal/p2p/pairing/pairing.go
• https://github.com/Liquid-co/OpenSave/blob/f2acdc9ef48ddb9ffff56a8707b1b5ba6bd47f5a/internal/cliapp/cliapp.go

[outlyer]

That worked perfectly. I wrapped it in a trivial shell script:

PEER=$(curl -s -H "Accept: application/json" -X GET http://127.0.0.1:8383/api/peers | jq '.pairingRequests[].peerId')
curl -X POST http://127.0.0.1:8383/api/peers/approve \
  -H 'Content-Type: application/json' \
  -d "{\"peerId\":\"${PEER}\"}"

And your advice is well noted, I am only exposing the port in my private network.

Incidentally, the app builds and runs quite well on macOS. I'm not sure if you have the build environment for it, but both the frontend and the cli are working. As of now, I am running the frontend on a Mac and PC and the daemon on a Linux host. All three are communicating happily. I just need to adjust the path translations and we should be good to go.

Thanks again.