Skip to content

Releases: ToolsEnabled/toolsengine

ToolsEngine 0.1.8

Choose a tag to compare

@ToolsEnabled-Inc ToolsEnabled-Inc released this 15 Oct 11:13

ToolsEngine 0.1.8 adds native Windows installation checks and a self-distributed Codex plugin. Windows paths require fixed local NTFS, conservative raw ACL/owner and retained ancestor validation; unsafe/reparse/overlap paths fail closed. The plugin exposes eight file/public-web/status/discovery tools with browser and desktop control off, validates matching source/lock/native-helper bytes in a separately prepared durable runtime, and protects both physical program roots. Startup downloads nothing and does not change client approvals.

Validated source: 4396c25a09543a8b0a9ca9ad0e3888fd47b26e4a, including the ready OpenAI plugin branch. Two offline Linux builds each passed 254 tests, with 22 platform skips, across 55 files; both release archives and two npm packs reproduce byte-for-byte.

Native execution was tested on Windows 10 Pro 22H2 x64 build 19045, Node 22.14.0 and Windows PowerShell 5.1.19041.6456. Each elevated engineering and restricted medium run passed 10 native source tests, 10 actual ancestor cases and 11 final-archive acceptance steps. Checks include Unicode installation, all 3,868 installed files' raw/private/inherited ACLs, stdio/file/CRLF and path/hardlink/junction refusals, both launcher roots, helper-identity mismatch, EOF, damaged payload, interrupted-state refusal and uninstall preserving workspace. All installed files were current-user-owned in the medium run; the elevated run's administrator-owned files are recorded separately. The medium token measured integrity 8192, TokenElevation=false, privileged groups deny-only and only SeChangeNotifyPrivilege; both administrator-only canaries were denied.

A different worker followed the public docs from fresh folders in both contexts: 16/16 install/check/list/version, eight-tool stdio/file/refusal, recheck and uninstall checks passed each. Every run ended with zero owned processes and deleted its temporary task. The no-browser route and native plugin entry were exercised directly; no real Windows Codex host/model or console GUI was launched.

The complete native Windows regression does not pass. A second elevated engineering run attempted all 55 files: 276 tests, 232 passed, 27 failed and 17 skipped. It used three declared external test-fixture adaptations and a confined synthetic account profile; the published runtime and dependencies were unchanged. Failures include dedicated-profile cookie persistence and installer/profile or platform assumptions still being diagnosed. The first attempt also remains recorded: its first file reached a 600-second timeout during fixture cleanup after 16 successful subtests. No complete native-suite or filtered-user full-suite pass is claimed. The documented eight-tool no-browser qualification above remains the tested Windows scope; independent headless-browser acceptance is pending. Any published source correction will require a new patch release.

Owner acceptance remains pending for interactive browser/desktop features and the real Windows Codex client. Windows 11 is untested. Actual Codex 0.162.1 marketplace/model-task evidence covers Linux on the merged lead branch. This is self-distribution, with no OpenAI directory listing or approval claim. No product account or paid model API is required. Interrupted Windows install recovery remains manual. The npm .tgz is a downloadable asset; no npm registry publication was performed.

Download the matching platform archive and checksum, follow its INSTALL.txt, and read app/docs/CODEX.md for the separate plugin/runtime setup. Eight release files are attached, including both platform archives, npm source package, checksums and build report. Release assets are downloaded back and compared byte-for-byte as part of publication verification.

ToolsEngine 0.1.7

Choose a tag to compare

@ToolsEnabled-Inc ToolsEnabled-Inc released this 14 Oct 01:45

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 `works...

Read more

ToolsEngine 0.1.6

Choose a tag to compare

@ToolsEnabled-Inc ToolsEnabled-Inc released this 13 Oct 18:33

ToolsEngine 0.1.6

A patch release of 0.1.5 (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.5: 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 code review of
0.1.5 found. The most important: a browser click, key press or navigation
that had already acted on the page could be reported as an error saying
nothing was saved, which invites the assistant to do it again; and the
automatic page snapshots were never removed, so in a workspace that is kept
every browser call came back that way after about 256 of them.

Source: commit eff891050be0c92427d37110d47b21be206e17cf (branch main). Built on Linux with Node
v22.19.0; the archive timestamps are the commit time, 2026-10-13T18:01:55Z. Licence:
MIT.

Files in this release

File Bytes SHA-256
toolsengine-0.1.6-linux-x64.tar.gz 7935943 6a57126a4d64c7169298da63cccbfa72eb648ad26ff2a89c62f9e296de8443aa
toolsengine-0.1.6-windows-x64.zip 9883946 7d75cabfabe4272211e08994a3b5790de0b39a961f8e3f052c812285ab9c899b
toolsenabled-toolsengine-0.1.6.tgz (the npm package, 22 files) 122830 a85e995dd181a68fdf1f4ceeafe71cb44404674bae1c5e8cdfd4853477839986
SHA256SUMS the two archive hashes above, sha256sum -c format
toolsenabled-toolsengine-0.1.6.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.6-linux-x64.tar.gz
cd toolsengine-0.1.6-linux-x64
./install.sh --register claude codex

On Windows: certutil -hashfile toolsengine-0.1.6-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.6 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.6.tgz.sha256
npm install -g ./toolsenabled-toolsengine-0.1.6.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.6

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

  • A browser call that had already clicked, typed or navigated was reported
    as an error ("Saved artifact size or number limit reached; nothing was
    saved." or "Another artifact writer is active or its output lock needs
    review; nothing was saved.") when the page-snapshot file that is written
    after it could not be saved. The page had changed, and the error invited
    the assistant to repeat the action: to place an order or send a message
    twice. Now the call's own result stands; the link to the missing file is
    replaced, and one sentence says that the action was carried out, that
    only its snapshot file was not saved and why, and not to repeat it.
  • Automatic page snapshots (page-<date and time>.yml in
    artifacts/toolsengine) are no longer kept forever. In 0.1.5 the 256-file
    limit filled after about 256 browser calls in a workspace that is kept,
    and from then on every browser call failed as above, install.mjs check
    included. Now the newest 64 (within 16 MiB) are kept and older ones are
    deleted when a new one is written and when the server starts, so a
    workspace that 0.1.5 filled keeps only its newest 64 after the first
    start. Files saved under a name given to a tool, screenshots, PDFs, logs,
    downloads and files you put there yourself are never deleted.
  • A write waits up to 2 seconds for another ToolsEngine on the same
    workspace that holds the output lock (Claude Code and Codex registered on
    one workspace, for example) instead of being refused at once. A lock that
    is still held after that is named in the refusal:
    .toolsengine-runtime/artifact-write.lock.
  • workspace.search no longer fails as a whole, losing the matches it had
    found, when a file or folder in the tree has a name that Linux allows and
    Windows does not: a colon, as in server-2026-10-13T10:00:00.log, a
    trailing dot or space, a device name such as aux.c. It passes them by
    and counts them as skipped.nonPortableNames. The descriptions of
    workspace.read_file, workspace.write_file and workspace.search and
    the README say which names the file tools refuse.
  • Case-insensitive workspace.search reports the column in the line as
    written on lines with letters whose lower case is longer, such as the
    Turkish "İ" (0.1.5 reported column 10 instead of 6 for İİİİ token).
  • web.extract finds the end of a script or a style on pages that contain
    "İ": script source no longer comes out as text there, and the text after
    a style is no longer lost.
  • install.mjs uninstall no longer stops with "ReferenceError: unexpected
    is not defined" after removing the files when a leftover folder cannot be
    read; it names that folder as unreadable and goes on to name the
    workspace and the commands that remove the client registrations.
  • workspace.write_file writes names of up to 255 bytes (0.1.5 failed on
    names of about 214 to 255 bytes, because its temporary file was named
    after the target), and a longer name is refused with "... has a name that
    is longer than this file system allows" instead of the system's
    ENAMETOOLONG error with the workspace's full path.

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: 252 tests, 232 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 48 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 fix has a test that fails on 0.1.5 and passes on this commit. For the
first: with the saved-output limit full of other files, and then with
another writer's lock held, a click on a "Place order" button in Chrome is
reported as carried out and the page counts one order per click (on 0.1.5
the navigation before it already returned "nothing was saved"); 300
automatic snapshots written into one workspace all succeed and leave the
newest 64 (0.1.5 refused the 257th and every one after it).

npm test with every file at once on the same commit: 252 tests, 232 pass, 0 fail, 20 skipped with
Chrome named by TOOLSENGINE_TEST_BROWSER; 252 tests, 208 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); 252 tests, 200 pass, 0 fail, 52 skipped
with Chrome hidden; and 252 tests, 193 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), and sha256sum -c on the npm package'...

Read more

ToolsEngine 0.1.5

Choose a tag to compare

@ToolsEnabled-Inc ToolsEnabled-Inc released this 13 Oct 14:02

ToolsEngine 0.1.5

A patch release of 0.1.4 (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.4: 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 second new-user
check of 0.1.4 found: npm test failing on a machine without Chrome, raw
system errors for a missing folder or workspace, the npm route without a
browser, and three smaller points in the installer, the README and two tool
descriptions.

Source: commit cc6aa379ec946a0c12fe975c066ef477c45931b8 (branch main). Built on Linux with Node
v22.19.0; the archive timestamps are the commit time, 2026-10-13T13:47:34Z. Licence:
MIT.

Files in this release

File Bytes SHA-256
toolsengine-0.1.5-linux-x64.tar.gz 7930697 9683a019653b69af91aac86aec6b380f83bc7a97c27e33eb4e252edd6b718c37
toolsengine-0.1.5-windows-x64.zip 9878944 7099d3a18dfedf48657ada87cff99509cdddff0c03e56b64ee49c66f954ee984
toolsenabled-toolsengine-0.1.5.tgz (the npm package, 22 files) 117632 abd14b41a3f3e51e36c7b917e02f84591b9a3023231d80838048c414919a2ee1
SHA256SUMS the two archive hashes above, sha256sum -c format
toolsenabled-toolsengine-0.1.5.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.5-linux-x64.tar.gz
cd toolsengine-0.1.5-linux-x64
./install.sh --register claude codex

On Windows: certutil -hashfile toolsengine-0.1.5-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.5 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.5.tgz.sha256
npm install -g ./toolsenabled-toolsengine-0.1.5.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.5

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

  • npm test passes on a machine without Google Chrome and Microsoft Edge,
    as the README says it does. The five tests that need an installed Chrome
    (four of the extension relay, which looks Chrome up before it opens its
    connect page, and one of the browser start options) are skipped there with
    the reason "needs an installed Google Chrome". In 0.1.4 one of them failed
    and four ran into their time limit.
  • workspace.write_file into a folder that does not exist says so in plain
    words: "The folder notes does not exist in the workspace.
    workspace.write_file does not create folders: write the file into a folder
    that exists (workspace.list shows them), or have the person create this
    folder first." Reading or listing a path that does not exist says "...
    does not exist in the workspace." 0.1.4 gave the system's ENOENT ... lstat error with the workspace's full path.
  • A --workspace that names an absolute folder that does not exist is
    refused with "--workspace must name an existing absolute directory. PATH
    does not exist: create the folder first, or name one that exists." instead
    of the system's ENOENT error.
  • The README's npm section says to use --no-browser where Chrome and Edge
    are absent.
  • When the installer does not run the clients because the terminal's home
    folder is not your own profile, it no longer suggests its own register
    command, which is refused for the same reason; it prints the clients'
    commands only.
  • The README says that npm run audit:package needs a checkout that other
    accounts can read (made under umask 022), and how to fix one made under
    umask 077.
  • browser.snapshot and browser.find remain not marked read-only, and
    their descriptions now say why: they do not change the page, but with
    filename they add a new file to the workspace, and their first call
    starts the browser or connects to it.

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: 238 tests, 218 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 47 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.

npm test with every file at once on the same commit: 238 tests, 218 pass,
0 fail, 20 skipped with Chrome named by TOOLSENGINE_TEST_BROWSER; 238, 195
pass, 0 fail, 43 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); 238, 187 pass, 0 fail, 51 skipped with
Chrome hidden; and 238, 180 pass, 0 fail, 58 skipped with no browser at all.
0.1.4 with Chrome hidden gave 1 failure and 4 cancelled tests.

From the extracted Linux archive on the build machine: sha256sum -c --ignore-missing SHA256SUMS answered OK for the Linux archive (exit 0), 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.sh --home DIR --browser none copied the 3,855 files, checking each against release.json; the installed server answered as toolsengine 0.1.5 with 8 tools, and install.mjs check and list worked. The claude mcp add command the installer printed, run with a separate Claude Code configuration folder, gave ✔ Connected in claude mcp list. With a home folder that is not the profile, --register claude printed the client commands without suggesting install.mjs register (exit 2). Over stdio the installed server refused workspace.write_file into a missing folder and a missing --workspace with the new messages. npm install -g ./toolsenabled-toolsengine-0.1.5.tgz installed the program without running any install script or downloading a browser; toolsengine --version printed ToolsEngine 0.1.5, 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, and the Windows 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 pl...

Read more

ToolsEngine 0.1.4

Choose a tag to compare

@ToolsEnabled-Inc ToolsEnabled-Inc released this 13 Oct 10:20

ToolsEngine 0.1.4

A patch release of 0.1.3, 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 and its tools are unchanged from 0.1.3: 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 new user found installing 0.1.3 from its release page: the
README's npm route, the missing verification step, the security policy
missing from the archives, and the installer's answer to a bare --version.

Source: commit 545be649e189356009c2a3fe78b9dff6df646f7d (branch main). Built on Linux with Node
v22.19.0; the archive timestamps are the commit time, 2026-10-13T09:36:50Z. Licence:
MIT.

Files in this release

File Bytes SHA-256
toolsengine-0.1.4-linux-x64.tar.gz 7927913 7c4b8a8fea54e5fa1a6a2b8794ed95536f4310588f5fb6f65de837f57273f460
toolsengine-0.1.4-windows-x64.zip 9877019 8eab155d94917d0729dde798e5152aab828bb6b617ee57e5113e43d890ac9140
toolsenabled-toolsengine-0.1.4.tgz (the npm package, 22 files) 115716 bfa22c869490018dd0728c513a0c4020b76b3b035a42368ec786dda8fd8f9a2e
SHA256SUMS the two archive hashes above, sha256sum -c format
toolsenabled-toolsengine-0.1.4.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.4-linux-x64.tar.gz
cd toolsengine-0.1.4-linux-x64
./install.sh --register claude codex

On Windows: certutil -hashfile toolsengine-0.1.4-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.4 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.4.tgz.sha256
npm install -g ./toolsenabled-toolsengine-0.1.4.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. 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.4

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

  • The README says that @toolsenabled/toolsengine is not on the npm
    registry yet and shows the route that works: npm install -g of the
    toolsenabled-toolsengine-0.1.4.tgz file above, after checking it against
    its .sha256 file. 0.1.3's README gave npm install -g @toolsenabled/toolsengine as if the package were on the registry.
  • The README no longer says that the npm route installs the dependency
    versions listed in npm-shrinkwrap.json: npm install -g of the 0.1.4
    file with npm 10.9.3 on 2026-10-13 took 92 of the 97 packages at those
    versions and 5 at newer ones (@hono/node-server, content-disposition,
    express, ip-address, zod). The archives carry exactly the tested
    versions.
  • The README's install steps check the archive against SHA256SUMS
    before extracting it: sha256sum -c --ignore-missing SHA256SUMS on Linux
    (without --ignore-missing the check also reports the Windows archive,
    which the file lists, and exits 1), certutil -hashfile on Windows.
  • SECURITY.md, the security policy with its safe harbor, is a file of the
    npm package (22 files now) and sits at the top of each archive beside
    LICENSE and NOTICE; INSTALL.txt lists it. 0.1.3's archives were cut before
    the file was added to the repository. The README names the security and
    support contact and the policy page in place of the sentence that left
    them to "the distributor".
  • The installer answers a bare --version on the install command with the
    same explanation as --version VALUE ("--version is for register, check,
    list and uninstall. An install is always this installer's version.")
    instead of "--version needs a value".
  • package.json keeps homepage https://toolsenabled.ai/toolsengine/,
    which answered 404 when 0.1.3 was checked and is a live page now.

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: 235 tests, 215 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 47 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. 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. npm test with every file at once on the same commit also passed: 235 tests, 215 pass, 0 fail, 20 skipped.

From the extracted Linux archive on the build machine: sha256sum -c --ignore-missing SHA256SUMS answered OK for the Linux archive (exit 0), 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. ./install.sh with Chrome named by path copied the 3,855 files, checking each against release.json; the installed server answered as toolsengine 0.1.4 with 27 tools and opened a blank page in Chrome; install.mjs check, list and uninstall worked as the README says, a second install into the same folder was refused, and a bare ./install.sh --version gave the new explanation (exit 1). Over stdio the installed server offered 27 tools with Chrome (sandbox on, dedicated temporary profile) and 8 with --no-browser. npm install -g ./toolsenabled-toolsengine-0.1.4.tgz installed the program without running any install script or downloading a browser; toolsengine --version printed ToolsEngine 0.1.4, and the server offered 8 tools with --no-browser.

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, and the Windows 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 ...

Read more

ToolsEngine 0.1.3

Choose a tag to compare

@ToolsEnabled-Inc ToolsEnabled-Inc released this 13 Oct 05:27

ToolsEngine 0.1.3

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.

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.

Source: commit 9f86b0a38dafefc1c8ad6cb82b86d3f5c84b71d5 (branch
release/0.1.3). Built on Linux with Node v22.19.0; the archive timestamps
are the commit time, 2026-10-13T04:57:30Z. Licence: MIT.

Files in this release

File Bytes SHA-256
toolsengine-0.1.3-linux-x64.tar.gz 7926700 d38d298730ca1996dccdd0435712726b65fe137a837ef00dee1f3215ebecb0a4
toolsengine-0.1.3-windows-x64.zip 9872815 90bcfa4eeea99cac20b81e544549b95c0aeae9ec1e1048a518a5c9bcf419b131
toolsenabled-toolsengine-0.1.3.tgz (the npm package, 21 files) 113393 99ac2317595e20c301389676189ebe387de4e96057597c6bafd27a310b489959
SHA256SUMS the two archive hashes above, sha256sum -c format
toolsenabled-toolsengine-0.1.3.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 and the 97 third-party
packages it 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; it carries that
tree's record, npm-shrinkwrap.json, for npm to follow.

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.3-linux-x64.tar.gz
cd toolsengine-0.1.3-linux-x64
./install.sh --register claude codex

On Windows: 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.3 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's npm install -g @toolsenabled/toolsengine
line will work once it is):

sha256sum -c toolsenabled-toolsengine-0.1.3.tgz.sha256
npm install -g ./toolsenabled-toolsengine-0.1.3.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. 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.3

Compared with 0.1.3-rc.5, this release carries the version number and these
corrections from its release review (the full candidate history is at the
end of app/README.md):

  • web.fetch asks for the certificate check in every request, so it stays on
    when NODE_TLS_REJECT_UNAUTHORIZED=0 is in the server's environment, and
    reports an over-limit body sent without a Content-Length as
    RESPONSE_TOO_LARGE instead of INVALID_RESPONSE.
  • On Linux the browser process is given its own XDG_CONFIG_HOME in the
    workspace's runtime folder, so an installed Chrome no longer keeps its
    crash-report database under ~/.config/google-chrome.
  • Startup refuses --browser-executable together with --browser-channel,
    checks the --cdp-endpoint address itself and refuses the options for a
    browser ToolsEngine would start alongside it, and refuses an overlapping
    --profile-dir before creating its folders. The installer refuses
    --version on the install command instead of ignoring it.
  • A browser started before the downloads folder is found tampered with is
    closed with the refusal. On Linux, socket directories left by a killed
    server are removed by the next server that needs one, and what a killed
    server leaves behind is stated. Calls still queued when shutdown starts are
    refused as shutdown, not as cancelled.
  • browser.take_screenshot no longer lists scale as required; its default
    css stays. The release build refuses a browser test that was skipped for
    a reason it does not know.
  • Documentation: the registration commands shown are the ones the installer
    prints; the tested-platforms list says what ships for --browser-extension;
    docs/clients.md and NOTICE no longer call the package a candidate, and
    docs/clients.md is provider-neutral.
  • The README describes the npm route ("From npm"), and package.json names
    the repository, the home page and where to report a problem.
  • npm run audit:package reads the curation record from
    reference/curation.json in the package tree when the record beside the
    source is absent, so the check runs from the public repository as well.

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: 235 tests, 215 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 47 test files, with Google Chrome (/opt/google/chrome/chrome)
and the browser sandbox on, on Linux. 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 21 packed files world-readable.

Tested platforms: Windows 10 and Linux with Node.js 22. 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.

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/; the repository's SECURITY.md was added
after this release was cut and is not inside the archives).