meshbay.git/packages/meshbay-node/tests, branch 0.20

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

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(node): a removal made at the machine is in audit.db

2026-10-15T12:24:44Z

The Node page and the CLI remove access through the loopback API, and revoke and unpin there wrote nothing to audit.db; only the signed MNP door did. A removed person's next connection then showed an auth_failed with nothing before it to explain it. Both routes now record member_revoke and member_unpin once the operation has succeeded, with the node's own account as the actor and 127.0.0.1 as the address, which tells the two doors apart. A refusal changes nothing and records nothing. Co-Authored-By: Claude Opus 5.5

fix(packaging): ship only the TMDB token line of QE/default.env

2026-10-15T12:24:25Z

build-node.sh and build-node-runtime.ps1 copied QE/default.env whole into every deb, rpm and Windows build after checking only its first 30 bytes. The file is unversioned and sits beside other QE notes, so any line added to it later would have gone out publicly. Only its first line ships now, and only once it is exactly MESHBAY_TMDB_DEFAULT_TOKEN=; a missing file, a BOM, a token not on the first line or an empty one still stop the build. The Linux step is run by a test against a scratch repo; the PowerShell one has the same rule and was not run here. Co-Authored-By: Claude Opus 5.5

refactor(chat): no thread_id — chat has no threads

2026-10-15T10:57:51Z

Nothing ever set it (the page and the CLI sent null) and nothing read it (the node's get_thread had no caller). It is no longer sent by the page or the CLI, in clear or in the sealed payload, nor relayed or served by the node; get_thread and its index are gone, and the protocol and design docs no longer name it. The node still accepts a chat_msg carrying one, from the desktop apps and CLIs already installed, and drops it. The column stays, empty, in chat.db: a node downgraded to an older version names it in every query. Co-Authored-By: Claude Opus 5.5

fix(node): an operator who was a member first holds the authority at once

2026-10-15T10:32:24Z

A member pinned on the node who then redeems the operator pairing code was written down as the operator but the node kept its "nobody can authorize" flag until it restarted: every admin operation — removing a folder, inviting, the apps' settings — was refused meanwhile. Only a key paired fresh set it. The join result now names `operator` for an account holding the node-wide operator row, whatever its row in the group says. The page and the CLI read that role to know what to offer, and refused before asking deletions the node would have accepted. Nothing is granted by it: every admin operation is still checked against the operators' keys. Co-Authored-By: Claude Opus 5.5

feat(hub): one account, several linked nodes

2026-10-15T07:33:28Z

An account links up to MAX_NODES_PER_ACCOUNT node keys (node_keys table) instead of the one users.pk_node_ed25519; the migration carries each account's key over and the downgrade keeps the last one linked. /v1/nodes/auth accepts any linked key, and its token names the key that won it (nk). PUT /me/node_key adds a key, idempotently, 409 past the limit; DELETE /me/node_key names the key: a browser session any of its own, a node only its own. Unlinking a key closes that node's socket and refuses its tokens at once, on REST and on the socket; the account's other nodes are untouched. /pubkeys no longer gives a node key to other accounts, and gives the caller its last linked one, which installed desktop apps read. The node reports waiting_for_node_key while its key is unlinked and signs in again as soon as the hub says so, so a key linked again is back within seconds; unlinking itself signs in first to hold a token naming its key. Profile -> Linked nodes lists each node (connected, last seen, IP, linked since, This machine in the desktop app) with Copy and Unlink, and adds a key by hand. The Node page banner, Create group and the desktop app add this machine's key instead of replacing another's. Messages that pointed at Settings -> Link Node point at Profile -> Linked nodes. Co-Authored-By: Claude Opus 5.5

fix(node): a chat-epoch notice answers no request, not even the asker's

2026-10-14T22:56:04Z

Revoking a device or removing a member opens a chat epoch, announced to everyone connected to the group, the asker included. Sent inside the handler, the asker's copy was stamped with its request's id and arrived as the answer to device_revoke, before the real one. It now leaves outside the reply context. Co-Authored-By: Claude Opus 5.5