Platform
macOS
Operating system version
macOS Tahoe 26.5.2 (25F84)
System architecture
ARM64 (M1, M2, etc)
PolyScope Version
0.24.1
Bug description
On a Mac mini running as an always-on server, one specific workspace makes the
server's relay connection collapse into a permanent reconnect loop as soon as a
remote client subscribes to it. Other workspaces on the same server are fine.
It happens both from the desktop app and from the mobile web client.
The workspace that fails has a far larger history:
| Workspace |
messages |
MB (messages.content) |
sessions |
| workspace-a |
15,363 |
40.3 |
40 |
| workspace-b |
262 |
0.6 |
3 |
| workspace-c |
0 |
– |
0 |
workspace-a alone is 40.3 MB of a 48 MB polyscope.db, and 40.3 of the
41.1 MB of message content stored in the whole database.
It is not one oversized payload: the largest single message is 110 KB and the
mean is 2.7 KB. messages.metadata is negligible too (0.7 MB across the entire
database), so those figures account for essentially all of the stored state.
It looks like the cumulative volume pushed to the client on subscribe.
Nothing is logged on either machine. The only lines in main.log are
[updater] No update available.
Context: workspace-a had a long-running Autopilot goal going for two days.
When the Claude session limit is hit the SDK fires a burst of retries
(~23 messages), each opening a session — hence 40 sessions. So the history
inflates over time and the problem gets progressively worse.
Steps to reproduce
- Have a server with one large-history workspace and one small one.
- From a remote client on a different network (desktop app or mobile web), open
the large workspace.
- On the server, watch the outbound relay socket:
lsof -nP -iTCP -sTCP:ESTABLISHED | grep -i polyscope | grep -v 127.0.0.1
- Switch the client to the small workspace and watch again.
Observed
With a client subscribed to the large workspace, the server's relay socket never
survives ~5 s — new fd, new source port, new handle on every sample, with gaps
where no connection exists at all. Reconnect bursts fire three simultaneous SYNs
to the three getpolyscope.com Cloudflare addresses every 8–12 s.
tcpdump shows each attempt completing the TLS handshake, transferring roughly
50–85 KB, then closing — consistent with a state transfer that never finishes.
Switching the client to the small workspace stabilises the socket immediately:
same handle and source port held for minutes. Switching back breaks it again
within seconds. Reproduced several times in both directions.
Reproduced from the desktop app and from the mobile web client.
The server process itself is healthy throughout: 3 d 06 h uptime, no crash
reports, 1.1 GB of 24 GB RAM, zero swap.
Expected
A workspace with a long history should stay reachable remotely — ideally by
paginating or lazily loading history instead of pushing the whole thing on
subscribe. At minimum the failure should be logged instead of surfacing as an
intermittent "Disconnected" with nothing in main.log.
Ruled out
- Process health: uptime, memory and swap all normal (above).
- macOS App Nap and power management (
pmset fully configured for always-on).
- Network topology / double NAT.
- Tailscale: identical behaviour with it disconnected, and
tcpdump shows relay
traffic leaving via the LAN address straight to Cloudflare, never via 100.x.
- Duplicated server identity:
serverId and serverIdentity in
~/.polyscope/settings.json differ between the two machines.
- Oversized individual message or metadata: max 110 KB, mean 2.7 KB, metadata
0.7 MB total.
- Client-specific issue: reproduced from two different clients.
Relevant log output
Platform
macOS
Operating system version
macOS Tahoe 26.5.2 (25F84)
System architecture
ARM64 (M1, M2, etc)
PolyScope Version
0.24.1
Bug description
On a Mac mini running as an always-on server, one specific workspace makes the
server's relay connection collapse into a permanent reconnect loop as soon as a
remote client subscribes to it. Other workspaces on the same server are fine.
It happens both from the desktop app and from the mobile web client.
The workspace that fails has a far larger history:
messages.content)workspace-aalone is 40.3 MB of a 48 MBpolyscope.db, and 40.3 of the41.1 MB of message content stored in the whole database.
It is not one oversized payload: the largest single message is 110 KB and the
mean is 2.7 KB.
messages.metadatais negligible too (0.7 MB across the entiredatabase), so those figures account for essentially all of the stored state.
It looks like the cumulative volume pushed to the client on subscribe.
Nothing is logged on either machine. The only lines in
main.logare[updater] No update available.Context:
workspace-ahad a long-running Autopilot goal going for two days.When the Claude session limit is hit the SDK fires a burst of retries
(~23 messages), each opening a session — hence 40 sessions. So the history
inflates over time and the problem gets progressively worse.
Steps to reproduce
the large workspace.
lsof -nP -iTCP -sTCP:ESTABLISHED | grep -i polyscope | grep -v 127.0.0.1Observed
With a client subscribed to the large workspace, the server's relay socket never
survives ~5 s — new fd, new source port, new handle on every sample, with gaps
where no connection exists at all. Reconnect bursts fire three simultaneous SYNs
to the three
getpolyscope.comCloudflare addresses every 8–12 s.tcpdumpshows each attempt completing the TLS handshake, transferring roughly50–85 KB, then closing — consistent with a state transfer that never finishes.
Switching the client to the small workspace stabilises the socket immediately:
same handle and source port held for minutes. Switching back breaks it again
within seconds. Reproduced several times in both directions.
Reproduced from the desktop app and from the mobile web client.
The server process itself is healthy throughout: 3 d 06 h uptime, no crash
reports, 1.1 GB of 24 GB RAM, zero swap.
Expected
A workspace with a long history should stay reachable remotely — ideally by
paginating or lazily loading history instead of pushing the whole thing on
subscribe. At minimum the failure should be logged instead of surfacing as an
intermittent "Disconnected" with nothing in
main.log.Ruled out
pmsetfully configured for always-on).tcpdumpshows relaytraffic leaving via the LAN address straight to Cloudflare, never via
100.x.serverIdandserverIdentityin~/.polyscope/settings.jsondiffer between the two machines.0.7 MB total.
Relevant log output