G9BrowserAgent 3.2.1

Download

System	File	Updates
Windows 10/11 (x64)	G9BrowserAgent-Setup-3.2.1.exe — per user, no administrator rights	Automatic: G9BrowserAgent checks these releases, downloads in the background and asks before installing
macOS 12+ (Apple silicon)	G9BrowserAgent-3.2.1-mac-arm64.dmg	G9BrowserAgent tells you when a release is out; download it and replace the app (the app is not signed with an Apple Developer ID yet, so macOS cannot install updates into it)
macOS 12+ (Intel)	G9BrowserAgent-3.2.1-mac-x64.dmg	As above
Linux (x64)	G9BrowserAgent-x86_64.AppImage — keep this file name: updates replace the file in place	Automatic, like Windows
Debian/Ubuntu (x64)	G9BrowserAgent_3.2.1_amd64.deb	G9BrowserAgent tells you; install the new .deb with your package manager

The installers are not code-signed: Windows SmartScreen and macOS Gatekeeper ask once before the first start. See the README for what to click, and for the browser extension (loaded once, updated by G9BrowserAgent itself).

latest.yml, latest-mac.yml and latest-linux.yml are the update metadata G9BrowserAgent reads; the .zip and .blockmap files are for the updater.

What changed in 3.2.1

Why. The product's name is G9BrowserAgent — the repository's, the GitHub releases' — but the app,
the extension, the installer and every screen said "G9". The owner asked for one name everywhere,
before anyone depends on the old one: in the app and the extension, in the files people install and
in what they read, and for the data folder and the AI clients' entry too.

What was renamed. Every mention of the product (1,571, by one script with its exceptions spelled
out, then read through): the app (G9BrowserAgent.exe, G9BrowserAgent.app, the Linux command
g9browseragent, /opt/G9BrowserAgent, the .deb package g9browseragent), the release files
(G9BrowserAgent-Setup-<v>.exe, G9BrowserAgent-<v>-mac-<arch>.dmg/.zip,
G9BrowserAgent-x86_64.AppImage, G9BrowserAgent_<v>_amd64.deb), the extension (its manifest name and
toolbar title; the description was shortened to stay within the store's 132 characters, which the
panel suite checks), the window, tray, notifications, the MCP server's name (G9BrowserAgent), the
AI clients' entry (g9browseragent), the data folder (%LOCALAPPDATA%\G9BrowserAgent,
~/.g9browseragent), the updater's cache, and the guides, both READMEs and their pictures (made
again). Kept, on purpose (docs/INSTALL.md, "Upgrading from G9"): G9_* variables, g9d and its
protocol (a new app must still recognise an old daemon), runner/g9.mjs, g9.project.json, the
export format id, the Docker image's /opt/g9, and this change log's older entries, which describe
what those versions were called.

Existing installs follow by themselves.

• The data folder moves once (lib/home.mjs, a copy in desktop/lib/paths.mjs): one atomic rename
  by one of its owners — the daemon at its start or the desktop app; every other caller only looks,
  the old folder until the move and the new one after — only for a folder that is
  recognisably G9's, and not at all while something holds files in it (Windows) — then the old folder
  stays in use by every component until a later start. A migrated-from.json note makes the app say
  so once and send Setup back to the extension step: the browser knows an unpacked extension by its
  folder.
• AI clients' entries (migrateRegistrations): an old-name entry moves to the new name — unchanged
  when its files exist (a developer's checkout), pointed at the app when they are gone; an entry naming
  a vanished executable is repointed; commented files and deliberate entries are left for Setup.
• Start at sign-in follows the new executable (Windows Run key, Linux autostart file).
• The .deb replaces g9-desktop (fpm --replaces/--conflicts/--provides).

Found on the way.

• Only the folder's owners may move it. The first version moved the old folder from every
  resolver, and twice that moved the owner's real %LOCALAPPDATA%\G9: a one-line check of
  resolveHome(), and later the update test's own browser lookup (engine/find.js, run by the
  harness in the real environment). Both times it was put back at once, unchanged. Now only the
  daemon at its start and the desktop app move it (migrate: true); every other caller only looks —
  the old folder until the move, the new one after — so a library call, a script or a test never
  moves a person's data, and all components still agree. After the change, a full check.mjs --all
  and the update test left the real folder where it was. Two daemon tests resolved the real default
  home too; they now run against a temporary profile. And the update
  end-to-end test started the packaged app with the real user profile — with the new start-up
  migration, that would have rewritten this machine's AI-client configs to point at a temporary
  install. The test now gives the app a profile of its own (USERPROFILE/HOME/APPDATA/XDG_*)
  and seeds an old-style g9-browser entry there to check that it follows the rename.
• The first migration rule repointed every old-name entry at the installed app, which would have
  silently replaced a developer's entry naming their repository. Now only a stale entry is repointed.
• setup/unit/mcp-http.test.mjs (3.2.0) ended with process.exit(0) while its sockets were closing;
  Node 24 on Windows aborts on that (a libuv assertion). It now exits a moment later.

The 3.2.0 pipeline failure. Its log could not be read from here (the credential available reads
code, not builds). Every stage the pipeline runs was repeated on 3.2.0 instead: all 18 offline checks
on Windows under Node 22 (the pipeline's version), the Linux job in a clean Node 22 container, and the
Windows packages with the update test (20 of 20). All passed, so the failure is in a stage that needs
the pipeline itself — most likely Publish, whose first step validates the Azure DevOps and GitHub
tokens stored in the pipeline: they were to be revoked after 3.1.1.

Runs on 3.2.1 (2026-09-27). check.mjs --all 16 of 18 on the owner's workstation — the two others
fail only there and pass from a clone elsewhere (the self-test's flow library finds the owner's own
g9.project.json in a folder above the repository) and under Node 22 (mcp-http, fixed
above). The update end to end on Windows 11, 3.2.0 → 3.2.1 across the rename, 21 of 21: the
3.2.0 install (G9.exe) updated through its own updater, stayed in its folder as
G9BrowserAgent.exe, and its old g9-browser AI-client entry was moved to g9browseragent and
pointed at it; every earlier scenario passed too.

Version 3.2.1 in package.json, extension/manifest.json, desktop/package.json and
desktop/package-lock.json.

SHA-256

c2d2da183c9b8333a7db046284806c02d29e69ae5d70e2298e9d6fc0ec996099  G9BrowserAgent-3.2.1-mac-arm64.dmg
113eb0fcfd3bc4c8fab148bd18b92d3d6b4af2baa4324cf9cd6bcd7a86a2d63e  G9BrowserAgent-3.2.1-mac-arm64.dmg.blockmap
52579108d9d0628c529cad9661b88ae301405964833e61131f702c8ab400bace  G9BrowserAgent-3.2.1-mac-arm64.zip
b69080202880063a0e7e9bee1d0a429a6870b0cc7715c3b836748298c5065309  G9BrowserAgent-3.2.1-mac-arm64.zip.blockmap
2421621d34417149fc532322c4179f27becf6fee282bc82d36c1bfe25dbb45ba  G9BrowserAgent-3.2.1-mac-x64.dmg
18ae258b2143f5468d13e4ab9962f78628818096d916b640ec8c7ee0b9bf5009  G9BrowserAgent-3.2.1-mac-x64.dmg.blockmap
0dced21dad19afe71833c704879b89f4079012b10367ecd331def0a725bf92bd  G9BrowserAgent-3.2.1-mac-x64.zip
f4cb0b2db566af232374dba51a543db787d9d296c2413a93630efc6a2bb16bb4  G9BrowserAgent-3.2.1-mac-x64.zip.blockmap
b11c8b41f294f6130f88a419f0a565c20d011ec30b1fd5a387b331553f66de3b  G9BrowserAgent-Setup-3.2.1.exe
b5454aec555cc401558b6f440bc98ed8118fba123dd793ef8144b12f79eef93b  G9BrowserAgent-Setup-3.2.1.exe.blockmap
915f011dd27ee1ccf7f0b9993e42f490dcc43b3dba4864bb95bfd3a514f800c2  G9BrowserAgent-x86_64.AppImage
38c5535580f830f53e8d35284de24920b36c3c29fb0223b9cfe7bd4668442114  G9BrowserAgent_3.2.1_amd64.deb