Repository navigation
feat: bots and browsers on Linux and macOS - #95
Merged
Merged
Conversation
embed-resource is a build dependency on Windows hosts only, so build.rs must not name it elsewhere.
- With no scheduled task off Windows, finding one answers 'not installed' instead of failing, so saving the settings works. - The owner name falls back to LOGNAME and the home folder name. - file: URLs keep the leading slash of POSIX paths, so bots can open pages from their folders.
- The config test's TOML literal had one backslash too many; Windows paths hid it by merging the separators. - The installed binary has no .exe off Windows, so the expected names are sorted like the listing. - Archiving a queued message holds the bot's start, so a fast start can no longer take the message first.
First slice of Linux/macOS support (spec 18, item 8). The Ubuntu job covered only core and store; it now runs clippy and the tests of the default members, with macOS alongside. The app crates join when the app runs there.
After PATH, look in ~/.local/bin (native installer), ~/.claude/local, /opt/homebrew/bin and /usr/local/bin, for a profile that never added it to PATH.
- A process group per bot and per browser takes the place of the Job Object: stopping kills the whole group. The job interface now prepares the command and takes the child, so the runtime and the browser have no Windows blocks left. - Bots get the environment of the owner's login shell (read once per 20 s), so they find what the owner's terminal finds even when the system starts the daemon with a bare PATH. - The owner's full name comes from the account entry. - The browser is the first Edge, Chrome or Chromium installed. Spec 14.1 describes it, and what is still missing: the group does not die with the daemon until slice 3.
The browser's stderr is read until it ends, and the line that best says why it stopped (a sandbox or namespace failure, else the first fatal one) goes into the error the bot and the owner see. Nothing of it is logged.
…untu runner - On macOS the page runs no Cmd shortcut from the virtual key, so Cmd+A, C, X, V, Z and Shift+Cmd+Z the owner presses go with their editing command. The macOS runner showed it: Cmd+A did not select the field. - The Ubuntu runner image ships Edge and Chrome with sandbox helpers that are not setuid root, so they refused to start; CI sets them the way their packages do.
… time The browser's stderr is kept as the line that best explains a failure for as long as it runs, so a browser that hangs at start says why too. The tabs test prints the list when it is not the one expected.
Edge's first start on a new Linux machine (the Ubuntu runner) took over 20 s, past the 10 s the daemon waited; a start that works takes under a second either way. CI starts Edge once before the tests instead of the diagnostic step.
Edge is the rarer one on Linux, and on the Ubuntu runner it took seconds to open the first tab of each new profile, past the 5 s the daemon waits, where Chrome took under one. CI no longer starts Edge before the tests.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Second slice of Linux/macOS support (spec 18, item 8). Bots and their browsers run off Windows the way they do on Windows.
Changes
SIGKILLto the whole group, likeTerminateJobObject.ProcessJobnow has one interface on both systems (prepare(&mut Command),assign(&Child),terminate()), soruntime/pipe.rsandbrowser/launch.rslose theircfg(windows)blocks.$SHELL -l -c, a marker, thenenv -0), cached for 20 s, with a fallback to the daemon's environment.CreateEnvironmentBlock: a daemon started by systemd or launchd with a barePATHstill finds~/.local/binand Homebrew.PATH,~/.local/bin,~/.claude/local,/opt/homebrew/binand/usr/local/bin.getpwuid_r.browser/program.rsfinds Edge, Chrome or Chromium:/Applicationsand~/Applications.PATH.Still missing (spec 14.1)
When the daemon dies, a group does not die with it the way a Job Object does.
claudeexits on stdin EOF, but a browser stays. Slice 3 handles this: thesystemd --usercgroup on Linux, a sweep at start on macOS.Checks
chromium+chromium-sandbox, non-root user):-D warningsand the full suite, three runs in a row, all green.PATH, parsingenv -0output,claudefound in~/.local/bin.botloftdsuite.Manual test with real Claude Code (not done yet)
cargo run -p botloftd -- servewith a devBOTLOFT_HOME.pnpm devwith?live) and chat with it.claudeorchromeprocess is left (pgrep -a).claudeis found when it is only in~/.local/bin.What CI on the real runners showed (fixed here)
commands). Elsewhere nothing changes.