meshbay.git, branch 0.20

test(cli): a Chrome that does not come up is not left running

2026-10-15T15:57:27Z

Its constructor gave up with the browser still running and no object to close it: eight headless Chrome processes were found hours after a failed Windows run. Co-Authored-By: Claude Opus 5.5

chore: bump version to 0.20.0

2026-10-15T15:45:41Z

Co-Authored-By: Claude Opus 5.5

build: ignore the Windows build's work directories; a Linux mode check off Windows

2026-10-15T15:45:41Z

packages/meshbay-client/build/_pip-audit (and its siblings) is made by the Windows build and was untracked noise. test_packaging_default_env checked a POSIX file mode that Git's bash on Windows cannot set. Co-Authored-By: Claude Opus 5.5

fix(packaging): setup ends a command-line client run from its install

2026-10-15T15:45:41Z

A `meshbay-cli chat --follow` left open holds node-runtime's DLLs, so the previous version's uninstaller failed ("Failed to uninstall old application files"), a silent update included, and left the node it had stopped not running. stop-node.ps1 now ends a meshbay-cli.exe run from this install (-InstallDir, setup's $INSTDIR), and no other copy. Found through CIM, not Get-Process: setup runs the 32-bit PowerShell, which reads no path for a 64-bit process, and the first version of the stop matched nothing. The test runs the script in that PowerShell. Checked live: an update over a running follower now ends it, replaces every file and restarts the node. Co-Authored-By: Claude Opus 5.5

fix(cli): make the command-line client work on Windows

2026-10-15T15:45:41Z

Its suite had only run on Linux. On Windows, against a real hub and node and from the installed meshbay-cli.exe: - secrets.enc was written in text mode (os.open without O_BINARY): every 0x0A of the ciphertext became CR LF and the saved session "does not open with its key" on the next run. - isatty() is true for NUL, so a script run with `< NUL` or by the Task Scheduler was asked questions instead of told to pass --yes; output.terminal() checks for a real console. - Ctrl+C waited for the selector loop's next timer, up to half a minute in `chat --follow`; the loop now points the signal wakeup at its self-pipe, as the proactor does. - Right-click copy and paste raised: asyncio cannot start a process on the selector loop; the clipboard tool runs in a thread. - Tab completion of remote paths ran on the default (proactor) loop, which never opens a node, and wrote in the locale encoding; the PowerShell script now reads it as UTF-8. - `get -R` into a folder past MAX_PATH died with a traceback; get, put, the resume file and the interactive mode use the extended form at each disk call, as the node does. - `groups` showed a SQLite hub's naive UTC time as local time. The opt-in end-to-end suite now runs on Windows (16 tests: Chrome found under Program Files and started with the real environment, VLC as the player, Ctrl+C through a console of its own, PowerShell 5.1 completion of an accented name). Co-Authored-By: Claude Opus 5.5

feat(android): no text messages backup, and one build again

2026-10-15T13:09:58Z

READ_SMS sits behind restricted settings outside a store and Play keeps it for the default SMS application: not worth a second build. Co-Authored-By: Claude Opus 5.5

build: audit the shipped Python dependencies with pip-audit

2026-10-15T12:56:35Z

No lock file pins the dependencies, so each build installs the newest releases and what ships is only known once it has. packaging/audit_deps.py runs pip-audit then: build-common.sh on the venv before stripping it, build-node-runtime.ps1 on the environment before PyInstaller freezes it. A known vulnerability stops the build, unless its id is listed in packaging/pip-audit-ignore.txt with why it does not apply. No network only skips the audit with a warning, as does a pip-audit that cannot be installed or writes no report. pip-audit runs from a venv of its own, never from the one that ships. Our packages are not audited (not on PyPI), nor pip, setuptools and wheel, which do not ship. Checked with the real build-common.sh (79 packages, none known), with PyJWT 2.14 (the build stops on its two advisories, and goes on once they are listed) and offline (a warning, the build goes on). The PowerShell step was not run here. Co-Authored-By: Claude Opus 5.5

test(node): the event-loop disk guard watches os.stat again

2026-10-15T12:37:45Z

test_a_scan_asks_the_disk_nothing_from_the_event_loop patched Path.stat, and since the indexer learned Windows' long paths it calls os.stat(long_path(p)) and os.scandir instead: the guard saw no call at all, and asserting that the calls ran on the indexer's thread failed on an empty set. It watches os.stat and os.scandir now (Path.stat goes through os.stat too), counting what the root holds and not the root, whose availability check runs on the roots' I/O thread. Nothing runs on the loop; a stat added there makes it fail again. The node CLI's parser names itself: under `python -m pytest`, Python 3.14 named the program after the module, so test_cli_golden saw "python -m pytest" in the help. The installed meshbay-node was not affected. Co-Authored-By: Claude Opus 5.5

fix(auth): the sign-up notice links the privacy statement, with a space

2026-10-15T12:33:03Z

The link under the Register button was glued to the sentence before it: htm drops whitespace that holds a line break, so "deleted.Legal information". It also pointed at the hub's /legal/ index. Where an account is created is where GDPR art. 13 owes the person the information about their data, so it now links the privacy statement itself — /legal/confidentialite.fr.txt in French, /legal/privacy-statement.en.txt in every other language — on the hub that served the page, like every legal link. The sidebar's "Legal information" is unchanged. Checked in Chrome and Firefox (headless), in English and French. Co-Authored-By: Claude Opus 5.5

feat(auth): the recovery key never reaches the hub

2026-10-15T12:25:00Z

Ticking "also e-mail it to me" at registration sent the recovery key R in the register body, and the hub appended it to the verification e-mail: the hub saw R in clear on its way out, and the resend door — no captcha — let anyone who knew a pending username and address have the hub mail a "recovery key" of their choosing. The box is gone. The recovery screen offers "E-mail it to myself", a mailto: link that opens the person's own mail application with the key filled in; the desktop shell hands mailto: to the system (http, https and mailto only) and the Android shell to a mail application (ACTION_SENDTO). The CLI drops --email-recovery-key and prints the key, as before. The hub mails the code alone, and refuses a register that still carries a recovery_key rather than dropping it, so an older client offering the option cannot tell someone their key was sent when it was not. A mailbox holding R remains, with the reset code that reaches the same mailbox, enough to recover the account's identities; the link says so, and it is the person's choice. Checked in Chrome and Firefox (headless, the real page against a stubbed hub) and by the CLI's end-to-end registration against a local hub. The Android change was not built here, and the desktop link was not clicked in the application. Co-Authored-By: Claude Opus 5.5