What happens
relayfile-mount cannot hold its WebSocket event stream open. It logs this several times a minute and falls back to polling:
websocket read failed; falling back to polling:
failed to read JSON message: failed to read: read limited at 32769 bytes
32769 is 32 KiB + 1, so this reads as a message-size cap being hit by the first frame the server sends, not as a network fault.
Why this is not a one-box problem
Observed on two unrelated machines at the same time, both mounting workspace rw_7ccfea89 against https://file.agentrelay.com:
- an Agent37 sandbox — Debian 12,
4.19.0-gvisor, x86_64, daemon vendored in agent-relay@11.8.3
- a macOS laptop — daemon at
~/.agent-relay/bin/relayfile-mount
Different OS, different kernel, different architecture, different binary build, same failure. A Daytona sandbox on the same scope showed it too.
Impact
Sync is still correct — every direction completed via polling, so this did not produce data loss or a stale mirror in testing:
- file written inside the Agent37 box → read on the laptop, byte-identical
- file written on the laptop → read inside the box
- file written on Daytona → read in both
What is lost is latency and the point of the event stream. With --interval 1s the daemon reported intervalMs: 5000 and changes took ~15–20 s to appear on the far side. Every mount everywhere is silently running in poll mode.
Reproduction
Start any mount and watch the log:
relayfile-mount --base-url https://file.agentrelay.com \
--workspace <ws> --local-dir <dir> --remote-path <scope> \
--token <relay token> --interval 1s
The line appears within seconds of the first sync cycle and repeats indefinitely.
What would settle it
Whether the 32 KiB limit is on the client read buffer or the server's first frame — a workspace with a large file index would explain a first message that exceeds it, and this workspace is large (2,544 registered agents, a rw_7ccfea89 tree with thousands of pending entries). If that is the cause, the same mount against a small fresh workspace should hold the socket, which is a cheap check I did not run.
Found while measuring sandbox provider deployability (AgentWorkforce/sandbox#42). Not a sandbox fault, filed here separately at chief's request. No fix proposed — I do not own this code.
What happens
relayfile-mountcannot hold its WebSocket event stream open. It logs this several times a minute and falls back to polling:32769 is 32 KiB + 1, so this reads as a message-size cap being hit by the first frame the server sends, not as a network fault.
Why this is not a one-box problem
Observed on two unrelated machines at the same time, both mounting workspace
rw_7ccfea89againsthttps://file.agentrelay.com:4.19.0-gvisor, x86_64, daemon vendored inagent-relay@11.8.3~/.agent-relay/bin/relayfile-mountDifferent OS, different kernel, different architecture, different binary build, same failure. A Daytona sandbox on the same scope showed it too.
Impact
Sync is still correct — every direction completed via polling, so this did not produce data loss or a stale mirror in testing:
What is lost is latency and the point of the event stream. With
--interval 1sthe daemon reportedintervalMs: 5000and changes took ~15–20 s to appear on the far side. Every mount everywhere is silently running in poll mode.Reproduction
Start any mount and watch the log:
The line appears within seconds of the first sync cycle and repeats indefinitely.
What would settle it
Whether the 32 KiB limit is on the client read buffer or the server's first frame — a workspace with a large file index would explain a first message that exceeds it, and this workspace is large (2,544 registered agents, a
rw_7ccfea89tree with thousands of pending entries). If that is the cause, the same mount against a small fresh workspace should hold the socket, which is a cheap check I did not run.Found while measuring sandbox provider deployability (
AgentWorkforce/sandbox#42). Not a sandbox fault, filed here separately at chief's request. No fix proposed — I do not own this code.