Two related bugs hit users on Windows-hosted bash environments where marimo runs natively on Windows but the agent scripts run under a non-MSYS bash. Both come from scripts/discover-servers.sh and scripts/execute-code.sh assuming a POSIX shell on a POSIX OS.
Bug 1 — discovery picks the wrong registry path under WSL
Both scripts gate Windows-style location lookup on OSTYPE:
if [[ "$OSTYPE" == msys* || "$OSTYPE" == cygwin* ]]; then
servers_dir="$HOME/.marimo/servers"
else
servers_dir="${XDG_STATE_HOME:-$HOME/.local/state}/marimo/servers"
fi
Under WSL pointed at a Windows-native marimo install, OSTYPE=linux-gnu, so the script reads ~/.local/state/marimo/servers and never sees the real registry at $USERPROFILE\.marimo\servers.
Reproducer:
- Marimo running natively on Windows with
--no-token; registry file present at C:\Users\<u>\.marimo\servers\127.0.0.1_2718.json.
curl http://127.0.0.1:2718/api/sessions from inside WSL shows the live session.
bash scripts/discover-servers.sh returns [].
Bug 2 — SSE parser silently drops every event on Windows
execute-code.sh reads the event stream with IFS= read -r line and matches event: / data: literally:
while IFS= read -r line && [[ "$done_received" == false ]]; do
case "$line" in
event:*) current_event=\"\${line#event: }\" ;;
data:*) ...
esac
done < <(curl -sN ...)
marimo's HTTP server emits CRLF terminators (per the SSE spec). read -r only strips the LF, so the trailing \r keeps every literal-prefix pattern from matching on Git Bash and WSL. Result: stdout / stderr / done events are all dropped — the user sees no output even though the code ran.
Reproducer:
bash scripts/execute-code.sh --url http://127.0.0.1:2718 --session <id> -c \"print(1 + 1)\" prints nothing.
- Same POST via
curl.exe returns the expected event: stdout\ndata: {\"data\":\"2\n\"}.
Suggested fix
PR coming separately:
- For (1): probe a candidate list — XDG path,
~/.marimo/servers, and (if $USERPROFILE is set) a wslpath/cygpath translation of it — and pick the first directory that has registry files. Infer the "is Windows-native registry?" liveness-probe choice from the chosen path (e.g. */.marimo/servers), not from OSTYPE.
- For (2): one-line
line=\"\${line%$'\r'}\" immediately after the read. Cheap to do unconditionally.
Tested both fixes on Windows 11 / Git Bash with a live marimo session.
Two related bugs hit users on Windows-hosted bash environments where marimo runs natively on Windows but the agent scripts run under a non-MSYS bash. Both come from
scripts/discover-servers.shandscripts/execute-code.shassuming a POSIX shell on a POSIX OS.Bug 1 — discovery picks the wrong registry path under WSL
Both scripts gate Windows-style location lookup on
OSTYPE:Under WSL pointed at a Windows-native marimo install,
OSTYPE=linux-gnu, so the script reads~/.local/state/marimo/serversand never sees the real registry at$USERPROFILE\.marimo\servers.Reproducer:
--no-token; registry file present atC:\Users\<u>\.marimo\servers\127.0.0.1_2718.json.curl http://127.0.0.1:2718/api/sessionsfrom inside WSL shows the live session.bash scripts/discover-servers.shreturns[].Bug 2 — SSE parser silently drops every event on Windows
execute-code.shreads the event stream withIFS= read -r lineand matchesevent:/data:literally:marimo's HTTP server emits CRLF terminators (per the SSE spec).
read -ronly strips the LF, so the trailing\rkeeps every literal-prefix pattern from matching on Git Bash and WSL. Result: stdout / stderr / done events are all dropped — the user sees no output even though the code ran.Reproducer:
bash scripts/execute-code.sh --url http://127.0.0.1:2718 --session <id> -c \"print(1 + 1)\"prints nothing.curl.exereturns the expectedevent: stdout\ndata: {\"data\":\"2\n\"}.Suggested fix
PR coming separately:
~/.marimo/servers, and (if$USERPROFILEis set) awslpath/cygpathtranslation of it — and pick the first directory that has registry files. Infer the "is Windows-native registry?" liveness-probe choice from the chosen path (e.g.*/.marimo/servers), not fromOSTYPE.line=\"\${line%$'\r'}\"immediately after theread. Cheap to do unconditionally.Tested both fixes on Windows 11 / Git Bash with a live marimo session.