@orchestraworks/worker 0.0.139 → 0.0.141

package/README.md

@@ -27,6 +27,192 @@ docker run --rm --entrypoint worker <image> check --harness claude
 
 `worker version` prints the version and the protocol versions this build speaks.
 
+## Make a machine image
+
+`worker install-machine` makes the host it runs on into a machine image that a cloud starts machines from.
+Use it for your own image under a Launcher on Azure, the program you run in your own cloud. A machine you
+enroll yourself is not an image: run `orchestra install`, or `worker install --role worker`.
+
+```
+worker install-machine --cloud azure|aws [--harness <families>|none] [--egress-redirect] [--docker] [--node]
+```
+
+Run it once, as root on Linux or as an administrator on Windows, on a host that has never run the worker.
+Each step reads what is there, changes only what is different, and prints `ok: <step>` or
+`changed: <step>`. The first failure stops the run and names the step. You can run it again.
+
+`<root>` is the machine-wide root: `/var/lib/sfdk/worker` on Linux, `%ProgramData%\sfdk\worker` on Windows.
+
+| Step | When | What it does |
+|---|---|---|
+| preconditions | always | Refuses a host it is not written for. Refuses a host that has booted as a machine: a boot file or `<root>/state` is there. Refuses a running worker service. |
+| directories | Windows | Creates `<root>`, `C:\software-factory` and its `etc` folder for SYSTEM and Administrators only. Users can also read and run `C:\software-factory`, which holds the programs on the machine path. A folder that is already there is kept as it is. |
+| package | always | Copies this release package to `<root>/package`. The service runs from there, because a self-update replaces the package directory. |
+| agent account | Linux | Creates the `agent` account, uid and gid 1000, home `/home`, and gives `/home` to it. Another account at uid 1000 is kept. |
+| harnesses | `--harness` | Installs the named harness families and their Node under the root. `none` or no flag installs none: a family installs itself on its first turn, in about a minute. |
+| service | always | Defines the service, `SfdkWorker` on Windows and `sfdk-worker.service` on Linux. It restarts after a failure. The step does not start it. |
+| cloud | always | `azure`: at each boot, the start-up task runs `worker boot-files --cloud azure`, which writes the boot files from the VM's userData, and then the worker starts. `aws`: the worker starts at each boot, after the platform's user data, and an Azure start-up task or unit from an earlier run is removed. |
+| egress redirect | `--egress-redirect` | WinDivert and its inbound firewall rule on Windows, `iptables` on Linux. A Launcher machine does not need it. |
+| Docker | `--docker` | Windows containers, or rootless Docker for the `agent` account. |
+| Node | `--node` | The agent's own Node, on the machine path. On Windows a new Node keeps the packages that `npm install -g` put in its folder. |
+| check | always | Runs `worker check --profile launcher` for `azure`, and `--profile enrolled` for `aws`. |
+
+The hosts:
+
+- Windows Server 2025 x64, Core or Desktop, Generation 2, and Ubuntu 22.04 and 24.04, amd64 and arm64:
+  every step.
+- Another Windows Server, or another Linux with systemd and glibc: the required steps, `--harness` and
+  `--node`. `--docker` and `--egress-redirect` are refused, and on Linux `--cloud azure` is refused too.
+- Windows 11, another client edition of Windows, and a Linux without systemd: refused.
+
+The machine must reach these hosts. The command does not test them:
+
+- the platform, and its object store;
+- while you build the image: `registry.npmjs.org` and `nodejs.org`, and with `--docker`,
+  `download.docker.com`; on Windows with `--egress-redirect`, `github.com`; on Linux, the Ubuntu package
+  mirror.
+
+### Windows Server 2025 for a Launcher on Azure
+
+1. Create the build VM from Microsoft's Windows Server 2025 image, Generation 2, with
+   `--security-type Standard`. A Trusted Launch VM cannot be captured into the image definition of step 7.
+2. Install your toolchain.
+3. Download the worker package and check it against the digest npm publishes. In PowerShell, as an
+   administrator:
+
+   ```powershell
+   [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
+   $version = '<worker version>'
+   $meta = Invoke-RestMethod "https://registry.npmjs.org/@orchestraworks%2Fworker-win32-x64/$version"
+   $tarball = Join-Path $env:TEMP 'worker.tgz'
+   Invoke-WebRequest -UseBasicParsing -Uri $meta.dist.tarball -OutFile $tarball
+   $digest = [Security.Cryptography.SHA512]::Create().ComputeHash([IO.File]::ReadAllBytes($tarball))
+   if (('sha512-' + [Convert]::ToBase64String($digest)) -ne $meta.dist.integrity) { throw 'the download does not match the digest npm publishes' }
+   $unpacked = Join-Path $env:TEMP 'worker'
+   New-Item -ItemType Directory -Force -Path $unpacked | Out-Null
+   tar.exe -xzf $tarball -C $unpacked
+   ```
+
+4. Make the machine. Add `--harness claude` or another family to preinstall it:
+
+   ```powershell
+   & "$unpacked\package\worker.exe" install-machine --cloud azure
+   if ($LASTEXITCODE -ne 0) { throw "install-machine exited $LASTEXITCODE; the line above names the step that failed" }
+   ```
+
+5. Restart the VM until no restart is pending. Sysprep refuses to run, or stops, while one is pending.
+   This command shows `"restartPending":false` when none is:
+
+   ```powershell
+   & "$env:ProgramData\sfdk\worker\package\worker.exe" check --profile launcher --output json
+   ```
+
+6. Generalize with Sysprep:
+
+   ```powershell
+   & "$env:SystemRoot\System32\Sysprep\Sysprep.exe" /oobe /generalize /mode:vm /shutdown
+   ```
+
+   - Do not remove the built-in Administrator account. Azure renames it, so `Remove-LocalUser` fails, and
+     Sysprep resets it.
+   - An installed SQL Server is generalized only through SQL Server's own image preparation, as Microsoft
+     documents for SQL Server and Sysprep.
+
+7. Capture the VM into an image definition in your Azure Compute Gallery. The Launcher creates Standard
+   security VMs, and on the `Dsv6` sizes it uses the NVMe disk controller, so the definition declares both:
+
+   ```bash
+   az vm deallocate --resource-group <rg> --name <vm>
+   az vm generalize --resource-group <rg> --name <vm>
+   az sig image-definition create --resource-group <rg> --gallery-name <gallery> \
+     --gallery-image-definition <definition> --publisher <publisher> --offer <offer> --sku <sku> \
+     --os-type Windows --os-state Generalized --hyper-v-generation V2 \
+     --features "SecurityType=TrustedLaunchSupported DiskControllerTypes=SCSI,NVMe"
+   az sig image-version create --resource-group <rg> --gallery-name <gallery> \
+     --gallery-image-definition <definition> --gallery-image-version 1.0.0 \
+     --virtual-machine "$(az vm show --resource-group <rg> --name <vm> --query id --output tsv)"
+   ```
+
+   Keep the quotes around `--features`: without them the Azure CLI refuses the second feature as an
+   unrecognized argument.
+
+8. Name the image version's resource id in the environment's `image`.
+
+### Ubuntu for a Launcher on Azure
+
+1. Create the build VM from Canonical's Ubuntu 22.04 or 24.04 image, Generation 2, with
+   `--security-type Standard`.
+2. Install your toolchain.
+3. Download the worker package and check it against the digest npm publishes. On arm64 the package is
+   `worker-linux-arm64`:
+
+   ```bash
+   version='<worker version>'
+   curl -fsSL "https://registry.npmjs.org/@orchestraworks%2Fworker-linux-x64/${version}" -o worker.json
+   tarball="$(python3 -c 'import json; print(json.load(open("worker.json"))["dist"]["tarball"])')"
+   integrity="$(python3 -c 'import json; print(json.load(open("worker.json"))["dist"]["integrity"])')"
+   curl -fsSL "${tarball}" -o worker.tgz
+   [ "sha512-$(openssl dgst -sha512 -binary worker.tgz | base64 -w0)" = "${integrity}" ] ||
+     { echo "the download does not match the digest npm publishes" >&2; exit 1; }
+   mkdir -p worker && tar -xzf worker.tgz -C worker
+   ```
+
+4. Make the machine:
+
+   ```bash
+   sudo ./worker/package/worker install-machine --cloud azure
+   ```
+
+5. Generalize. This removes the account you built with, so no machine made from the image carries it.
+   Run it from `/`, because it deletes your home directory, and the Azure agent stops with an error
+   when its working directory is gone:
+
+   ```bash
+   cd / && sudo waagent -force -deprovision+user && export HISTSIZE=0 && sync
+   ```
+
+6. Capture as in the Windows steps, with `--os-type Linux`.
+7. Name the image version's resource id in the environment's `image`.
+
+If the image serves an app, end your own boot step with one request to the app. The first request after
+a boot is slow, so this request takes that delay instead of the first user.
+
+### The model key and other tokens
+
+Give the agent its model key in one of three ways. Each works on every machine, with or without our
+egress edge. The edge and its Secrets are an addition, never needed for your own key.
+
+1. **The environment's `env`** (`provisionSpec.env`). The worker reads it when it starts. A declared value
+   replaces our image's placeholder, never a real value. The platform stores `env` values in plain text,
+   an environment read returns them, and the VM's startup data carries them. If that is not acceptable,
+   use route 2 or 3, or a Secret at our egress edge where one stands in front.
+2. **Baked into the image**, at machine scope, before Sysprep or generalizing. On Windows, that is the
+   `Environment` value (a multi-string) of `HKLM\SYSTEM\CurrentControlSet\Services\SfdkWorker`. Keep
+   the entries that are there, and add or replace only yours. On Linux, it is a drop-in on
+   `sfdk-worker.service`.
+3. **The `onStartAgent` hook** writes the harness's own key file in the agent's home:
+   `.claude/.credentials.json` for a Claude sign-in, `.codex/auth.json` for `codex`, or
+   `.pi/agent/auth.json` for `pi`. The worker keeps a real value it finds there. A raw Claude API key has
+   no file, so use route 1 or 2 for it.
+
+The names:
+
+- `claude` with an Anthropic API key or an Orchestra gateway key: `ANTHROPIC_API_KEY`. With a gateway
+  key, keep the agent's model gateway on. The platform sets the gateway address.
+- `claude` with a Claude subscription token: `ORCHESTRA_WORKER_CLAUDE_OAUTH_TOKEN`. A renewing sign-in:
+  `ORCHESTRA_WORKER_CLAUDE_ACCESS_TOKEN` and `ORCHESTRA_WORKER_CLAUDE_REFRESH_TOKEN`.
+- `codex`: `ORCHESTRA_WORKER_OPENAI_API_KEY`, or `ORCHESTRA_WORKER_CODEX_PERSONAL_ACCESS_TOKEN`.
+- `pi`: `ORCHESTRA_WORKER_OPENAI_API_KEY` or `ORCHESTRA_WORKER_CLAUDE_OAUTH_TOKEN`.
+  `ORCHESTRA_WORKER_PI_PROVIDER` chooses the provider.
+
+Never restart `SfdkWorker` or `sfdk-worker.service` to load a key. A restart after the worker registered
+stops the machine's work, and the platform parks the VM. The next message starts it again, 1 to 2
+minutes later.
+
+- A gateway key's `monthlyCreditCap` stops the key when it is reached. One short turn can cost about 30
+  credits, so a low cap fails the next turn with `budget_exceeded`.
+- If you restart a machine's VM yourself, the platform stops the VM. The next message starts it again.
+
 ## For coding agents
 
 - `orchestra worker --help` lists the worker commands. `orchestra worker <command> --help` gives their flags.

package/docs/REFERENCE.md

@@ -12,11 +12,11 @@ The worker exposes no API of its own. Every route it calls is the platform's.
 
 | path | what it holds |
 |---|---|
-| `cmd/worker/` | the one binary: `run`, `install`, `enroll`, `check`, `version` |
+| `cmd/worker/` | the one binary: `run`, `install`, `install-machine`, `boot-files`, `enroll`, `check`, `trust-nested`, `screen`, `version` |
 | `identity/` | the four identity exchanges — claim, refresh, reattach-challenge, reattach — the holder key, and the loop that keeps the machine token alive |
 | `broker/` | the protocol on the message broker: the connection, the register on every connect, the heartbeat and the status cadence, the pull of this machine's own work consumer, and the publisher every other package sends through |
 | `env/` | the machine-side environment the platform composes onto a launch, read from the names the contract declares |
-| `facts/` | what this build knows about the four harness families: the program to install and the digest that authenticates it, the environment each family is handed, the templates it seeds, and every location its content lands in — embedded in the binary, so one release digest covers the facts and the program that reads them |
+| `facts/` | what this build knows about the four harness families: the program to install and the digest that authenticates it, the environment each family is handed, the templates it seeds, and every location its content lands in; and, in `machine.json`, the pins of what `install-machine` puts on a machine beside the worker — Docker, WinDivert and the agent's Node — and where a launch's certificate files land. Both are embedded in the binary, so one release digest covers the facts and the program that reads them |
 | `harness/` | the only place family-specific knowledge lives: the launch plan, the content layout, the store lookup, the mid-turn message each family accepts, and the installer that puts the pinned Node and a family's programs under the worker root |
 | `process/` | the agent's setup and the harness process behind each session placement: the start, the stop and the last save a remove asks for, the startup fence over what a previous run left, and the stop of everything when the worker is told to stop |
 | `stream/` | the queue: every placement message and every prompt, steer and cancel pulled off this machine's work consumer, the ACP client that opens a session's harness conversation and runs its turns, each turn's events batched to the platform and published live, and the answer every placement message is owed |
@@ -94,10 +94,12 @@ shapes the schema ships, and nothing here re-declares one.
   **The machine-wide service is the image role's, and the role is the whole of what asks for it.** An
   `image` gets it — a property list under `/Library/LaunchDaemons`, a unit under `/etc/systemd/system`,
   a Windows service — because the platform builds the image with nobody logged in to it and nobody
-  typing the command, and the builder is already root. No flag selects that scope, on any role.
+  typing the command, and the builder is already root. No flag selects that scope, on any role. A
+  virtual-machine image is made by `worker install-machine` below, which our bakes run; the `image` role
+  stays for a container image, whose own command is the worker.
 
   `--root` follows the scope the same way: `~/.sfdk/worker` (`%LOCALAPPDATA%\sfdk\worker` on Windows) for
-  a `user` install, `/var/lib/sfdk/worker` (`%ProgramData%\orchestra\worker`) for the other two. A `user`
+  a `user` install, `/var/lib/sfdk/worker` (`%ProgramData%\sfdk\worker`) for the other two. A `user`
   install writes its log under that root, at `log/worker.log`, because no service manager in that scope
   keeps one a person can read.
 
@@ -137,10 +139,51 @@ shapes the schema ships, and nothing here re-declares one.
   family's programs, and `workspaces/<family>`, the directory that family's harness runs in — one
   create at install covers all three, and a worker enrolled on somebody's own machine can take no
   second one.
+- **`worker install-machine --cloud azure|aws [--os windows|linux] [--harness <families>|none]
+  [--egress-redirect] [--docker] [--node]`** makes the host it runs on into a machine image, in eleven steps
+  the package [README](../README.md) lists with the hosts each one runs on. It runs elevated, takes no
+  `--root` and installs under the machine-wide root. Each step reads the current state, changes only what
+  differs, reads the result back and prints `ok: <step>` or `changed: <step>`; the first failure stops the
+  run. So a second run on a converged host changes nothing, and a run that stopped part way is repaired by
+  running it again. It refuses a host that has already booted as a machine — a boot file or `<root>/state`
+  is there — because removing one is not a repair, and it refuses a running worker service. On Windows it
+  creates `<root>`, the install root `C:\software-factory` and its `etc` folder for SYSTEM and
+  Administrators alone, with Users also reading and running the install root, whose `bin` and `node` are
+  on the machine path; a folder already there is kept, so a host that made one first keeps its
+  permissions.
+
+  The service runs from a copy of the release package at `<root>/package`, because the self-update
+  replaces the directory the running binary sits in; the step compares that copy's `worker version`
+  with its own, and it refuses a package unpacked under `<root>/package` or holding it. The cloud step
+  owns the start type. `aws` starts the service at every boot, after the
+  platform's user data. `azure` cannot order the worker after its boot file on Windows, so there the
+  service is demand-start and the scheduled task `orchestra-azure-userdata` runs `<root>\package\worker.exe
+  boot-files --cloud azure` as SYSTEM at startup, with a 10-minute limit and three restarts a minute
+  apart; on Linux the oneshot unit `orchestra-azure-userdata.service` runs the same command, ordered before
+  the worker's unit, which requires it. Azure on Linux also installs WALinuxAgent's and azure-vm-utils'
+  udev rules, which name a data disk by its LUN. `aws` removes the Azure task, or the Azure unit and the
+  worker unit's link to it, that an earlier `azure` run left. The optional steps fetch what they install from the pins
+  in `facts/machine.json` and check each archive's SHA-256 — Node against `nodejs.org`'s published
+  `SHASUMS256.txt` — before anything is unpacked. A new Node on Windows replaces only the archive's own
+  files, `node.exe` last, so npm's global packages in its folder and their commands stay. The last step runs `worker check` in-process with the
+  profile that holds only what this command installs: `launcher` for `azure`, `enrolled` for `aws`. A
+  machine a person enrolls is not an image and keeps `worker install --role worker`; `--cloud none` is
+  refused and says so.
+- **`worker boot-files --cloud azure`** is the start-up task of an Azure image. It reads the VM's
+  `compute/userData` from the instance metadata service at `169.254.169.254` with the `Metadata: true`
+  header and no proxy, sixty times two seconds apart. The text is base64 of one JSON object of strings
+  with the keys `machine.env`, `transport-trust-roots.pem` and `egress-ca.pem`; an unknown key, a value
+  that is not a string or a missing `machine.env` fails the boot. `machine.env` goes where the EC2 lanes
+  put the boot file, the two certificates to the guest paths in `facts/machine.json`, and a known file
+  this boot does not carry is removed, so a resumed VM never reads its previous launch's file. Each file
+  is written under a staged name of its own, created new with its permissions before any byte, and
+  renamed into place: on Linux at modes `0600`, `0600` and `0644`, the egress authority being the one the
+  agent's programs read, and on Windows readable by SYSTEM and Administrators alone. On Windows it starts `SfdkWorker` last; on Linux systemd starts the worker's unit after this one ends.
 - **`worker enroll`** redeems the enrollment token this machine was given, prints the row it was
   issued, and then serves that machine. It does not stop at the redemption, because the holder key
   the redemption bound lives in this process.
-- **`worker check [--harness <families>] [--root <dir>]`** reads the runtime image contract from
+- **`worker check [--harness <families>|none] [--root <dir>] [--profile hosted|launcher|enrolled]
+  [--output json]`** reads the runtime image contract from
   inside an image, which is where the rest of that contract cannot be read. An inspection from the
   container runtime sees the command, the account it starts as, the platform it was built for and the
   version label; whether a family's programs are there at the versions this build's facts pin, whether
@@ -156,6 +199,18 @@ shapes the schema ships, and nothing here re-declares one.
   it is used. With no `--harness` it checks the rows that belong to no family and says so — a customer
   image installs the families it needs, so holding one to every family this build can host would
   refuse it for lacking programs nothing on it was ever going to run.
+
+  `--profile` names the machine the image is for, and each profile holds the image only to what that
+  machine runs. `hosted` is our own images: every row above, and on Linux `/home` owned by uid 1000
+  where it is not a mount point. `launcher` is a customer's image their Launcher starts, which has no
+  egress edge in front of it: no WinDivert and no CLI, and the `/home` row. `enrolled` is a customer's
+  image the platform's EC2 lane starts: no WinDivert, no CLI and no `/home` row. With no `--profile` the
+  check reads the `hosted` rows without `/home`, which is how the local environment runs it inside a
+  container whose `/home` nobody prepared, and reports no profile. `--output json` answers the rows as a
+  document with `held`, `missed`, `families` and, when a profile was named, `profile`; on Windows it
+  also carries `restartPending`, set while Component Based Servicing's `RebootPending` key, Windows
+  Update's `RebootRequired` key or the Session Manager's `PendingFileRenameOperations` value is there.
+  A pending restart is reported and never refused: Sysprep refuses to generalize while one is pending.
 - **`worker trust-nested [--registry <host>]... [--root <dir>]`** lets the containers this machine
   runs trust the egress edge, which nothing does by default. It reads the authority from
   `SFDK_EGRESS_CA_FILE`, which the worker sets on every harness process and on the setup script;
@@ -204,7 +259,7 @@ set is a concern this machine does not have.
 | `SFDK_EGRESS_LISTEN_PORT` | where the redirect lands, which is the shim's own listen port |
 | `SFDK_EGRESS_IPV6` | `true` mirrors the redirect through `ip6tables` |
 | `SFDK_EGRESS_PROXY` | `on`, the default, or `off`; `off` tells each harness that no edge of ours stands in front of this machine, as on an enrolled one. The platform writes `off` into every Launcher machine's boot file, because no proxy entrance of ours stands in front of one yet |
-| `SFDK_RUNTIME_ENVIRONMENT` | a whole environment folded into one JSON object of string values, for a boot file whose lines cannot carry a line break; each pair is placed unless already set, except that with `SFDK_EGRESS_PROXY=off` a pair replaces a name that holds exactly the image's egress placeholder |
+| `SFDK_RUNTIME_ENVIRONMENT` | a whole environment folded into one JSON object of string values, for a boot file whose lines cannot carry a line break; each pair is placed unless already set, except that a non-blank pair replaces a name that holds exactly the image's placeholder |
 | `SFDK_VOLUME_MOUNTS` | the volumes this launch declares, as one JSON document |
 | `SFDK_MACHINE_SLUG` | the machine's platform-minted slug: the leading label of its preview hostnames, and what the tunnel's upgrade signs |
 | `SFDK_TUNNEL_ENDPOINT_URL` | where the preview gateway serves its tunnel listener; its scheme is the whole TLS statement for that hop |
@@ -214,10 +269,10 @@ set is a concern this machine does not have.
 **The worker reads that file itself, on every operating system, and no service manager is handed it.**
 Every `worker run` places each pair into its own environment before it serves, leaving alone any name
 that is already set, so a person's own foreground run still wins over the file. One name already set
-is replaced: where the switch `SFDK_EGRESS_PROXY` is `off`, no edge replaces the image's placeholder
-credential on the way out, so a value the launch declared replaces a name that holds exactly a
-placeholder the family facts list. That is how a customer's own token in `provisionSpec.env` reaches the
-harness on a Launcher machine; it rides the machine's startup data in plain text. systemd's
+is replaced, on every machine: a non-blank value the launch declared replaces a name that holds exactly
+a placeholder the family facts list, whether or not an egress edge stands in front. That is how a
+customer's own token in `provisionSpec.env` reaches the harness; it rides the machine's startup data in
+plain text. systemd's
 `EnvironmentFile=` is deliberately not used: it processes backslash escapes in an unquoted value, so
 the two characters `\n` that carry a line break inside `SFDK_RUNTIME_ENVIRONMENT` would arrive as a bare
 `n` and the certificate folded in there would hold no certificate at all. A machine with no file
@@ -226,7 +281,8 @@ stops the start and is named.
 
 Where the file sits is the one thing that differs, and only because of who may write it. On a Linux
 machine the platform launched, cloud-init writes `/etc/sfdk/machine.env` from the user data and the run
-reads it; no install by a person writes there. A `worker` install that registers a service writes
+reads it; on an Azure machine `worker boot-files` writes the same file from the VM's userData, and
+`<root>\machine.env` on Windows. No install by a person writes there. A `worker` install that registers a service writes
 `<root>/machine.env` under the worker's own root — `C:\ProgramData\sfdk\worker\machine.env` on a default
 machine-wide Windows install — because an install that registers the worker in one person's own session
 cannot write under `/etc`. A Linux run reads both, the machine-wide one first. The platform's user data writes that file on a machine
@@ -260,7 +316,7 @@ things in place in one order that is not interchangeable:
    nothing behind it. On Windows an inbound firewall rule is written first as well: the rewritten
    packet arrives as an inbound connection, which Windows Server blocks by default.
 3. **The redirect** — `iptables` on Ubuntu, WinDivert on Windows. The two WinDivert files are loaded
-   by absolute path from `<root>\bin`, where the image bake stages them, and never through the
+   by absolute path from `<root>\bin`, where `install-machine --egress-redirect` places them, and never through the
    operating system's own search order: opening the driver installs and starts a kernel service.
 
 Each accepted connection's original destination is recovered (`SO_ORIGINAL_DST` on Linux, the

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@orchestraworks/worker",
-  "version": "0.0.139",
+  "version": "0.0.141",
   "type": "module",
   "description": "The Orchestra worker.",
   "license": "Apache-2.0",
@@ -22,10 +22,10 @@
     "docs/REFERENCE.md"
   ],
   "optionalDependencies": {
-    "@orchestraworks/worker-linux-x64": "0.0.139",
-    "@orchestraworks/worker-linux-arm64": "0.0.139",
-    "@orchestraworks/worker-darwin-x64": "0.0.139",
-    "@orchestraworks/worker-darwin-arm64": "0.0.139",
-    "@orchestraworks/worker-win32-x64": "0.0.139"
+    "@orchestraworks/worker-linux-x64": "0.0.141",
+    "@orchestraworks/worker-linux-arm64": "0.0.141",
+    "@orchestraworks/worker-darwin-x64": "0.0.141",
+    "@orchestraworks/worker-darwin-arm64": "0.0.141",
+    "@orchestraworks/worker-win32-x64": "0.0.141"
   }
 }