ChromeManager: batch managing many Chrome windows on the desktop

What the tool is for

ChromeManager is a desktop tool for batch management and synchronised operation across multiple browser environments. The README says it originally served the multi-window workflow needs of the NoBiggie community, and the project description calls it a Chrome multi-window manager that opens windows in bulk, arranges them, and synchronises operations between them to raise interaction efficiency.

The scope is stated as a list of capabilities. It supports Chrome, Edge, Opera and Brave environments with grouping. The synchronisation core was rewritten in Go to take advantage of concurrent processing, improving the responsiveness, efficiency and stability of mouse, keyboard, web page and extension popup synchronisation across many windows. It cleans environment caches safely to reduce storage used over time, repairs damaged extension installation files while keeping the original plugin data where possible, and exposes a local API so that automation workflows such as OpenClaw and Hermes can drive it.

The disclaimer at the top of the README is worth reading too, because it constrains use. The project is open source for learning and exchange and must not be used for any closed-source commercial purpose, users must obey local law, the developer accepts no liability for direct or indirect loss, and using the software means you have read and agreed to the disclaimer.

So the target user is a person with several browser sessions open at once, on one machine, who needs them to behave like one coordinated workspace rather than six separate applications.

The 2.0 to 4.0 rewrite and the module layout

The upgrade notes are the most informative part of the README, because they show what the current design is made of.

The architecture change is the headline. Version 2.0 was a Python monolith, Python with Tkinter and PyInstaller. Version 4.0 was rebuilt as a Go backend, a Wails 3 host and a Vite frontend, with a strict split: the backend handles window management, synchronisation, input, environments, files and system interaction, and the frontend handles the main interface, the settings page, the feature tabs, the modals and the status messages.

The project structure is modular, and the module names describe the system. There is a platform/ directory for platform capability abstraction, a syncmanager/ for synchronisation state and window information management, a utils/ directory for window arrangement, input management, icons, popup direction control and tab management, an api/ directory for the local automation API service, and a frontend/ directory for the Vite frontend and modular UI.

The build chain moved too, from build.py and PyInstaller to Task, Wails 3, Vite, the Go build and NSIS, and the README says the result is a more standard build process that makes it easier to extend to Windows, macOS and Linux versions.

The interface also moved from a script-tool look to a desktop application look, with a custom title bar, a main toolbar, a window list, a right-hand control area and feature tabs along the bottom. Browser type, paths, groups, keyboard shortcuts, icons, the API and the maintenance tools are all consolidated into one settings and dialog system.

How the synchronisation engine is structured

The synchronisation section is where the engineering detail sits, and the design is a master and follower model.

The synchronisation chain is driven by a clearer master window and follower window model, which decouples state management from window state management, and it introduces a more explicit synchronisation lifecycle to reduce the confusion that came up when switching the master, closing a window or running a batch operation.

The event path was strengthened around hooks, optimising the forwarding stability of high-frequency input events such as keyboard, mouse and scroll wheel. For Chromium pop-up windows it adds cached recognition and association handling, which improves the behaviour of plugin popups, extension menus and floating layers during synchronisation.

The resource control matters as much as the event path. The synchronisation chain introduces throttling, rate limiting, state verification and gentler failure handling to reduce jitter and false triggers under heavy load. When the master window closes it can automatically perform synchronisation convergence and state reclamation, which lowers the problems of leftover state and focus contention.

The shortcut and input features are the practical side. You can set a synchronisation toggle shortcut, and the input chain supports batch random number input, specified text input, file preview and input parameter validation.

The last detail is the one to keep in mind when watching it behave: the mouse, keyboard and page content all move at once, so a mis-click in the master window is a mis-click in every follower. That is the feature, and it is also why the throttling and the master selection matter.

Creating environments, arranging windows and the maintenance tools

The environment and window management features are what turn this from a script into a workflow tool.

Each group maintains its own shortcut path and cache directory independently, which is described as convenient for separate accounts, separate business lines and separate projects. Batch environment creation supports entering a numbered range directly, and the program generates the matching shortcuts and environment cache directories, and it can save the parameters from the last creation run.

The range syntax is flexible, and the README gives three examples.

1-10
1,3,5
1-10,15,18

So a contiguous range, a list of individual numbers, or a range combined with extras all work, which is the shape you want when you keep some slots for something else.

Window arrangement supports automatic arrangement, custom arrangement, multi-screen information detection, and persistence of the arrangement parameters so a layout can be reused. Batch web page opening supports saving and deleting URL presets, and tab management offers keeping only the current tab or only the new tab.

The maintenance features are the careful part. The safe bulk close path takes the synchronisation state, the master state and the environment release timing into account before closing, and offers an adjustable interval between closes. Cache cleaning scans the safe cache directory for the specified group and window numbers, skips running environments, and explicitly does not touch plugins, bookmarks, cookies, login data or Secure Preferences. Extension repair copies the extension installation file from a working environment into a damaged one when the data may still exist, which is meant to reduce the loss from a repair button that would reset the plugins.

The local API and the automation handoff

The local automation API is a distinct feature and the one that makes the app usable from other tools.

It supports a local interface on 127.0.0.1, with Token and port configuration, and it is designed to be called safely by external agents such as OpenClaw and Hermes. There is an automation panel with an entry point for those agents, a Skills repository address with installation instructions, and sample commands with basic usage hints.

The division of labour is stated explicitly. The external agent handles task understanding and process orchestration, while ChromeManager handles window preparation, batch navigation and the execution interface.

That is a sensible split for a window-level tool. A page-level automation library has no way to arrange a dozen windows and make them share a cursor, and an agent that wants a browser workspace prepared for it has no way to drive the operating system's window layer. The local API is where the app exposes the things an agent cannot do itself.

The security posture follows from being bound to localhost with a token, which is the right default for an interface that can open windows and inject input. It is worth noting that the API and the tool's other capabilities are available in the same process, so anything that can reach the token can drive the mouse on the machine.

Building the Windows and macOS versions

The build scripts are per platform, in subdirectories, and the README gives both the wrapper script and the underlying task commands.

On Windows you change into the Windows subdirectory and run the build tool.

cd "ChromeManager V4.0_win"
build.bat

The script checks the build environment and produces a release build with no console window, and the output is an executable at bin/ChromeManager.exe. You can also run the tasks directly.

cd "ChromeManager V4.0_win"
task build
task package

The task build command produces the release GUI program by default, and task dev is the one for development.

task dev

On macOS the equivalent is a build.command script in the macOS subdirectory.

cd "ChromeManager V4.0_mac"
bash ./build.command

The build tool checks the macOS requirements and offers build options.

The toolchain requirements for building from source are Go 1.24.3 or later, Node.js LTS with npm, Task, the Wails 3 CLI, plus NSIS for the Windows installer and the Xcode Command Line Tools for macOS.

For running a released build, the requirements are Windows 10 or 11 on 64-bit with a Chromium browser, and on a fresh system the Microsoft Edge WebView2 Runtime, or macOS 10.15 or later with a corresponding Chromium browser installed. The README recommends running with administrator rights for the synchronisation feature, which makes sense given that it hooks input and windows.

Where ChromeManager is the wrong choice

The first limitation is that it drives the window layer, not the page. There is no selector, no script, no wait condition and no assertion in any of the feature lists, and the automation panel hands window preparation to the app while the external agent does the thinking. A team that wants a reliable end-to-end test suite against a web application needs a browser automation library with a DOM model, and this is not one.

The second is the input synchronisation model itself. Mouse, keyboard and scroll events are mirrored from the master window to the followers, which means a mistake in the master is a mistake everywhere, and a follower window that opens a modal the master does not have can put the two out of step. The README describes workarounds for the Chromium popup case, with cached recognition and association handling, which is evidence that the hard cases are known rather than solved.

The third is the scale. Nothing in the documentation describes a hundred windows, and the design of master and follower with throttling and rate limiting suggests the practical ceiling is well below what a user might assume. The environment creation feature is aimed at numbered multi-account setups of a moderate size, not a farm.

The fourth is the licence and the disclaimer together. The code is under GPL-3.0, and the disclaimer states the project is for learning and exchange and must not be used for any closed-source commercial purpose, which is stricter than the licence alone would require. A company that wants to ship the tool inside a product is outside what the author intends, whatever the licence technically permits.

The fifth is that the documentation is Chinese-only. The README, the interface and the build instructions are in Chinese, so an English-speaking contributor is reading a translation of the intent rather than the intent itself, and the local API panel points at a Skills repository whose contents are not described in the repository at all.

Licence, maintenance and the cost of a windowing utility

The repository is under the GPL-3.0 licence, with a LICENSE file at the root and a licence badge in the README, and the project is attributed to the author Devilflasher, with links to an X account and a chat group.

The repository is not archived and the last push was on 2026-09-16, the same day as the v4.0.0 release, so the code is actively worked on. The release history is short, v4.0.0 in September 2026, v2.0 in May 2025 and v1.0 in April 2025, so the project only became a public release recently, and the 4.0 rewrite is the first version with a real architecture behind it.

The runtime requirements are modest for a tool of this kind. The badges state Go 1.24.3 or later, Wails 3 alpha, Vite 8.x, Windows 10 or later and macOS 10.15 or later, and a Go 1.24.3 badge is the one to check first if you are building from source.

The cost of adopting it is low in resources, since it is a desktop application with no server, and low in integration, since a released build is a single executable. The cost that does exist is in the model. A workflow built on synchronised windows inherits the behaviour of the synchronisation engine, including its latency, its throttling and its edge cases, and the master selection has to be right or a whole group of windows does the wrong thing together.

The directory structure in the repository is worth a final note, because it explains how the project is distributed. There are separate ChromeManager V4.0_win/ and ChromeManager V4.0_mac/ directories, a shared README.md, the LICENSE and a .gitignore with unified rules, which is a layout that treats the two platforms as parallel builds of one product rather than as one codebase with platform conditionals.

Editorial conclusion

ChromeManager suits someone running several browser sessions for separate accounts or projects who wants a single queue, one shared input and a repeatable way to rebuild the desktop state, since the sync engine and the environment creation are the two features that make manual window juggling unnecessary. It does not suit a browser automation suite, because the app drives the window layer rather than the page. Build it from source with the Windows or macOS build script before judging the sync latency, and note that the sync feature is recommended to run with administrator rights.

Frequently asked questions

Official sources

1. devilflasher/Chrome-Manager on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases