ToolsEngine 0.1.7

ToolsEngine 0.1.7

A patch release of 0.1.6 (0.1.3 was the first public release of
@toolsenabled/toolsengine): a local MCP server over stdio that gives an
agent client a sandboxed headless Chromium browser, file tools inside one
workspace folder, and a reader for public web pages. It runs on Windows 10 or
11 and on Linux (64-bit) with Node.js 22.14 or newer. The browser tools drive
Google Chrome or Microsoft Edge that is already on the machine; no browser is
bundled or downloaded.

The server offers the same tools as 0.1.6: 27 core tools, 19 browser.*, 4
workspace.*, 2 web.*, system.status and capability.find.
Attached-browser modes offer 26; without a browser, 8. Four desktop.* tools
for signed-in Windows apps exist only on Windows and only when the server is
started with the desktop option. This release corrects what a fresh-user
verification of 0.1.6 found: a --browser-executable path that does not
exist was accepted at startup, so the client showed a connected server whose
first browser call failed with the browser library's own text; the archive's
INSTALL.txt and the installer's own output did not say when the installer
prints the client commands instead of running them; and the description of
workspace.write_file did not say that it does not create folders.

Source: commit 4bfc0871b6396fc7e0c709f639357b11b02cb618 (branch main). Built on Linux with Node
v22.19.0; the archive timestamps are the commit time, 2026-10-14T01:25:51Z. Licence:
MIT.

Files in this release

File	Bytes	SHA-256
toolsengine-0.1.7-linux-x64.tar.gz	7939390	953ef770c0b077029718ec69b8601c085742d9f2bc74e868b3c6f1b65d6db9e2
toolsengine-0.1.7-windows-x64.zip	9885855	9eb8fa90bebe9df9b8f5a6b9407f791351e86c6f0e545311397568605522453f
toolsenabled-toolsengine-0.1.7.tgz (the npm package, 22 files)	124427	92a17ac631fcfa51188d2856204e64745f9c49bafdee0928943310f1fd4cb86c
SHA256SUMS		the two archive hashes above, sha256sum -c format
toolsenabled-toolsengine-0.1.7.tgz.sha256		the npm package hash, same format
release-report.json		the build record: commit, test counts, bundled packages, archive hashes

Each archive holds the program, the installer, SECURITY.md and the 97
third-party packages the program needs (THIRD-PARTY-NOTICES.txt lists them
with their licence texts: MIT 84, Apache-2.0 3, BSD-3-Clause 2, ISC 7, BSD-2-Clause 1). The npm package is the same program without the dependency
tree: npm fetches the dependencies from the registry when it installs the
file. It takes the four that package.json names at their exact versions
and resolves the packages they depend on itself, so some of those can be
newer than the tested versions listed in npm-shrinkwrap.json; the
archives carry exactly the tested versions.

Install

From an archive (nothing is downloaded; the installer uses no network).
Verify first; --ignore-missing lets the check pass with only the archive
for your platform downloaded:

sha256sum -c --ignore-missing SHA256SUMS
tar -xzf toolsengine-0.1.7-linux-x64.tar.gz
cd toolsengine-0.1.7-linux-x64
./install.sh --register claude codex

On Windows: certutil -hashfile toolsengine-0.1.7-windows-x64.zip SHA256
must print the hash in the table above; then Extract All on the .zip, open
a terminal in the extracted folder and run install.cmd --register claude codex. Name only the client you use. The installer copies the program to
ToolsEngine/0.1.7 under your profile, creates a workspace folder, finds
Chrome or Edge, starts the server once to check it, and registers it with
each named client's own command. INSTALL.txt in the archive and
app/README.md (the manual) have the details and every option.

From the npm package in this release (@toolsenabled/toolsengine is not
on the npm registry yet; the README says so and shows this route):

sha256sum -c toolsenabled-toolsengine-0.1.7.tgz.sha256
npm install -g ./toolsenabled-toolsengine-0.1.7.tgz
claude mcp add --scope user toolsengine -- toolsengine --workspace /absolute/path/to/workspace --browser-channel chrome
codex mcp add toolsengine -- toolsengine --workspace /absolute/path/to/workspace --browser-channel chrome

--browser-channel msedge chooses Edge, --browser-executable PATH a
browser by path, --no-browser leaves the browser tools out. With no Chrome
and no Edge on the machine, use --no-browser in place of
--browser-channel chrome: the server does not start with a browser it
cannot find, and Claude Code then shows only "Failed to connect".
Hand-written client configuration (JSON for Claude Code, TOML for Codex) is
in docs/clients.md in the package.

Then open a new session in the client: the tools appear under the server
name toolsengine, and system.status shows what is switched on.

Changes in 0.1.7

Compared with 0.1.6 (the full history is at the end of app/README.md):

• A --browser-executable path that does not exist is refused at startup,
  as a missing channel browser (--browser-channel chrome with no Chrome)
  already was. In 0.1.6 the server started with that path, claude mcp list
  showed it as connected with every browser tool, and the first browser call
  failed with "browserType.launch: Failed to launch chromium because
  executable doesn't exist at ...". Now the server does not start: it writes
  "--browser-executable names PATH, which does not exist." (or "... is not a
  file." for a folder, "... must be an absolute path" for a relative path),
  followed by the ways out (the full path of the browser program, or
  --browser-channel chrome / msedge; correct a client registration where
  it was made), to its error output and exits 1. Claude Code then shows
  "Failed to connect", and the message is in its MCP log. A path that exists
  is taken as before.
• INSTALL.txt in both archives now names --home DIR in its OPTIONS list,
  says that ~/ToolsEngine (C:\Users\YOU\ToolsEngine) is the account's own
  profile as the system records it, even when HOME (USERPROFILE) points
  elsewhere, and says that the installer runs a client only when that home
  is the account's own profile and CLAUDE_CONFIG_DIR / CODEX_HOME, if
  set, point inside it: otherwise it prints the two client commands for a
  terminal of your own and, with --register, ends with exit code 2. The
  installer's printed guidance in that case now says that the install is
  complete, why it ends with exit code 2, and that --home plays no part
  in it; --help names the exit code too. The README said all of this since
  0.1.5.
• The description of workspace.write_file says in so many words that it
  does not create folders, and why: a mistyped or invented path must not
  grow a tree of folders in the person's workspace, and workspace.list
  shows the folders that exist. The behaviour is unchanged since 0.1.6 (a
  write into a missing folder is refused in plain words); the README's
  "Tools" section explains the choice.

What was tested

The release build runs the whole test suite first, one file at a time, and
builds nothing unless every test passes and the browser tests ran. For this
build: 254 tests, 234 pass, 0 fail, 20 skipped for
the system they ran on (19 Windows-only cases: 16 desktop-tool tests, 2 installer tests and 1 NTFS short-name test; and 1 sandbox case that applies only to Playwright's own Chromium), in 49 test files, with
Google Chrome (/opt/google/chrome/chrome) and the browser sandbox on, on
Linux. The build was run twice from the same commit and gave byte-identical
archives, and npm pack run twice gave the same package file. The package
audit (npm run audit:package) passed: 27 offered tools, 4 optional Windows
desktop tools, the two tool catalogues equal to the running server, all 22
packed files world-readable.

Each change has a test that fails on 0.1.6 and passes on this commit:
parseConfig and the whole program with a missing path, a folder and a
relative path (the program exits 1 with the message on its error output and
nothing on its output; an existing file still passes); the installer's
printed guidance with another account's home; INSTALL.txt for Linux and
Windows; the workspace.write_file description.

npm test with every file at once on the same commit: 254 tests, 234 pass, 0 fail, 20 skipped with
Chrome named by TOOLSENGINE_TEST_BROWSER; 254 tests, 210 pass, 0 fail, 44 skipped as a plain npm test
(on this Ubuntu machine Playwright's own Chromium cannot set its sandbox up,
so the tests that would use it are skipped with that reason); 254 tests, 202 pass, 0 fail, 52 skipped
with Chrome hidden; and 254 tests, 195 pass, 0 fail, 59 skipped with no browser at all.

From the extracted Linux archive on the build machine: sha256sum -c --ignore-missing SHA256SUMS answered OK for the Linux archive (exit 0), sha256sum -c SHA256SUMS answered OK for both, and sha256sum -c on the npm package's .sha256 file answered OK. The test file shipped in the package (tests/browser-extension.test.js, run from app/ with the bundled packages) passed 17 of 17 with Chrome, and with Chrome hidden passed 13 and skipped 4 with the reason, 0 failed. INSTALL.txt in the Linux archive and in the Windows archive (CRLF) carries the --home DIR option, the own-profile sentence and the exit-code-2 paragraph. ./install.sh --home DIR --browser none copied the 3,855 files, checking each against release.json; the installed server answered as toolsengine 0.1.7 with 8 tools, and install.mjs check and list worked. The installed server started with --browser-executable /nonexistent/chrome wrote "--browser-executable names /nonexistent/chrome, which does not exist. ..." and exited 1 (0.1.6 started and offered 27 tools), and registered that way with a separate Claude Code configuration folder it showed ✘ Failed to connect in claude mcp list. Over stdio the installed server's workspace.write_file description says that it does not create folders and why, and a write into a missing folder was refused in plain words; the 0.1.6 checks (search beside a non-portable name, column after "İİİİ", 255-byte name written, 304-byte name refused without the workspace path) still hold. ./install.sh --home DIR --browser none --register claude with HOME pointed outside the profile printed the two client commands, said that the install is complete and why it ends with exit code 2, and exited 2. install.mjs uninstall with an unreadable leftover folder named it as unreadable and named the workspace (exit 0). The claude mcp add command the installer printed, run with a separate Claude Code configuration folder, gave ✔ Connected in claude mcp list. npm install -g ./toolsenabled-toolsengine-0.1.7.tgz installed the program without running any install script or downloading a browser; toolsengine --version printed ToolsEngine 0.1.7, and claude mcp add ... -- toolsengine --workspace DIR --no-browser gave ✔ Connected.

Tested platforms: Linux with Node.js 22 for this release; the Windows
archive was built and listed on Linux and was not run on Windows for this
patch (0.1.3 was tested on Windows 10; the changed code is platform-neutral
JavaScript, and the Windows desktop code is unchanged). macOS is untested.

Not included

• A Firefox-desktop mode that exists only in a separate, unreleased fork.
  It is not part of this package or its documentation.
• Native desktop input on Linux or macOS. The desktop tools exist on Windows
  only.
• A web browser. Chrome or Edge must already be installed.
• Publication on the npm registry. The npm package is the .tgz above.

Known limits

From "Tested platforms and known limits" in app/README.md:

• --browser-extension uses Microsoft's Playwright Extension installed by the
  person; its tests use stand-ins, and a real signed-in Chrome or Edge
  extension workflow was not verified.
• Browser network access is ordinary browser access, private networks
  included; only web.fetch has the public-address checks.
• The filesystem checks do not defeat a hostile local process racing path
  components; use an OS sandbox when that threat applies.
• There is no per-action confirmation, no on-screen "being controlled"
  indicator and no emergency stop key in this package; the MCP client's
  approval settings are the only check before an action.
• web.extract is a bounded tokenizer, not a full HTML rendering engine.
• Queued calls are refused once shutdown starts; a browser action already
  delivered cannot be rolled back.

Support and security contact: support@toolsenabled.ai (security policy:
https://toolsenabled.ai/security/, stated in SECURITY.md at the top of
each archive and in the npm package; private reports also through the
repository's Security tab).