Release Notes

Version 2.21.0 of the Sema4.ai extension for VS Code updates the extension's base environment (OpenSSL, Playwright and uv) and RCC, and changes how dependency checks treat openssl.

What changed

• OpenSSL 3.5.9. The base environment pins openssl=3.5.9.
• Playwright 1.64.1. The base environment pins playwright==1.64.1, which bundles Node.js 24.22.1.
• uv 0.13.7. The base environment pins uv=0.13.7.
• RCC v21.4.2. The extension now uses RCC v21.4.2. See the RCC v21.4.2 release note for details.
• Rebuilt prebuilt base environments for all supported platforms: Windows x64, Linux x64 and macOS (Apple Silicon).

The base environment is the Python environment the extension uses for its own tooling, such as recording browser locators. It doesn't change the environments your robots run in, which come from each robot's conda.yaml.

Dependency checks for openssl

In conda.yaml and package.yaml, the extension no longer suggests updating openssl to the latest version. As with python and uv, keep the version set in the template. If openssl is older than 3.5.9, the extension shows a warning to update it.

Getting 2.21.0

VS Code updates the extension automatically. To update right away, open the Extensions view, find Sema4.ai SDK and select Update.

The first time you open the Playwright inspector after updating, it may take some time to start, because it needs to download the browser for the new Playwright version.

🔗 Install from Visual Studio Marketplace

📄 Documentation

RCC v21.4.2 is a security release. The robot templates now pin OpenSSL to the long-term support line, so new robots no longer get an end-of-life OpenSSL.

There are no functional changes and no breaking changes in RCC itself. Upgrading is a straight swap.

Why

The templates that rcc robot initialize uses did not pin OpenSSL, so the conda solver picked the newest version that Python allows. python=3.12.8 accepts any OpenSSL 3.x from 3.4.0, so environments built from the templates got OpenSSL 3.6.5. The OpenSSL 3.6 line has reached end of life and no longer receives security fixes.

What changed

• The standard, python and extended templates pin openssl=3.5.9. OpenSSL 3.5 is the long-term support line.
• The environment that rcc configure speedtest builds pins the same version.

Existing robots

This release changes only the templates that new robots start from. A robot you have already created keeps its own conda.yaml, and gets OpenSSL 3.6 if that file does not pin OpenSSL. To move such a robot to the long-term support line, add the pin under dependencies:

RCC builds a new environment the next time the robot runs.

To check which OpenSSL an environment uses, run this in it, for example with rcc task shell:

Getting v21.4.2

Signed and pre-built executables are available directly:

• Windows — rcc.exe
• macOS (Apple Silicon) — rcc
• Linux — rcc

macOS and Windows builds are code-signed, and the macOS build is notarized. RCC supports macOS on Apple Silicon only; Intel builds were discontinued in v21.0.0.

The complete changelog ships inside the executable itself. Run rcc docs changelog to read the full list of changes for the version you have installed.

Breaking: Python 3.11 or newer

• All packages now require Python 3.11 or newer (#1367). Python 3.10 reached end of life in October 2026, and the security fixes below for pillow and dnspython exist only in releases that require Python 3.11. Every package gets a major version bump for this reason, also the ones with no other change. On Python 3.10, pip install rpaframework keeps resolving to 33.0.2.

• rpaframework now requires rpaframework-core ≥14.0.0, rpaframework-pdf ≥12.0.0 and rpaframework-windows ≥12.0.0, and every package that depends on rpaframework-core requires ≥14.0.0, so that upgrading any of them on an existing installation also brings in the patched pillow (RPA.PDF and RPA.Windows get pillow through rpaframework-core).

New: RPA.Decision

The new package rpaframework-decision (#1366) adds the RPA.Decision library: typed, calibrated decisions from decision models such as TypeSafe's hosted Jev and the open-weight Laya. Instead of parsing free text from a chat model, a decision model answers a fixed question with a choice, a confidence and the probability of every option, which makes thresholds and human hand-off straightforward. The same keywords are available in Robot Framework.

Keywords: Decide, Decide Or Escalate, Check (yes/no with a probability), Score (position on an ordered rubric), Rank Options, Ask Questions (several questions about one state in a single call), Classify Items and Require Confidence. Every decision is recorded in an audit log (Get, Save and Clear Decision Audit Log). Backends: jev (hosted), laya (local, via the laya extra), replay (a recorded log, for dry runs) and any Python callable, which also makes the library easy to test offline.

Security fixes

• Dependency bumps (#1367):

  • pillow ≥13.0.0 — 42 advisories, 5 of them CRITICAL (heap buffer overflows in JPEG, FlashPix and TIFF decoding, stale native storage reuse in multi-frame loaders, argument injection in the Ghostscript call), in rpaframework-core, rpaframework-recognition and rpaframework
  • certifi ≥2026.10.18 — CRITICAL, bundled emSign root CAs whose intermediate CA keys were compromised, in the lock files of all packages
  • pypdf ≥6.21.4 — HIGH, infinite loops and unbounded memory use on crafted PDFs (CVE-2026-115572, CVE-2026-115580, CVE-2026-115585, CVE-2026-119203 to CVE-2026-119209; further MEDIUM/LOW advisories), in rpaframework-pdf
  • fpdf2 ≥2.8.8 — MEDIUM, implicit loading of external URLs and local image paths from attacker-controlled content (CVE-2026-114609) and exponential SVG <use> expansion (CVE-2026-114610), in rpaframework-pdf
  • pyasn1 ≥0.6.5 — HIGH, quadratic-time denial of service in BER/CER/DER decoding (CVE-2026-119194 to CVE-2026-119197), in rpaframework-google
  • dnspython ≥2.9.0 — HIGH, excessive CPU use in dns.name.from_wire_parser() (CVE-2026-114605), in rpaframework
  • msgpack ≥1.2.3 — HIGH, unbounded memory leak in the C extension (CVE-2026-114613), in rpaframework-assistant
  • setuptools ≥84.1.0 — LOW, Windows path escape during legacy wheel installation, in rpaframework-sema4ai

• Known limitation: rpaframework still allows oauthlib 3.x because tweepy, a dependency of RPA.Twitter, caps it below 4. The advisories CVE-2026-49272 and CVE-2026-118669 concern the device-flow and token-grant endpoints of an OAuth server; the libraries use oauthlib only as a client. Which oauthlib you get depends on the installer: pip picks tweepy 4.17 with oauthlib 3.3, uv picks oauthlib 4.0.1 with the older tweepy 4.5, and that older tweepy cannot be imported on Python 3.13 or 3.14 (No module named 'imghdr'), so RPA.Twitter fails to import in that combination. A follow-up release will pin tweepy ≥4.14.

Fixes and improvements

• RPA.Windows: New keyword Control Parent Window, the counterpart of Control Child Window (#1368, fixes #1362). It walks up the element tree from an element found by a locator and makes the reached ancestor the active window, either a given number of levels up or up to the first ancestor of a control_type such as WindowControl or PaneControl. Locators after it resolve inside that ancestor, exactly as with Control Child Window:

• RPA.Robocorp.Process: List Process Work Items now retrieves every result page, so items beyond the first page are returned and included when filtering by state (#1361, fixes #1095).

• Releases are now built and published to PyPI by GitHub Actions from version tags (#1370), with the GitHub release notes generated from the same release-notes file. The daily install test and package workflows now also run when the shared development tooling changes (#1365).

Released packages

• package rpaframework 34.0.0
• package rpaframework-core 14.0.0
• package rpaframework-pdf 12.0.0
• package rpaframework-recognition 9.0.0
• package rpaframework-windows 12.0.0
• package rpaframework-decision 1.0.0 (new)
• package rpaframework-assistant 7.0.0
• package rpaframework-aws 9.0.0
• package rpaframework-google 13.0.0
• package rpaframework-hubspot 5.0.0
• package rpaframework-openai 6.0.0
• package rpaframework-sema4ai 2.0.0

The last six carry no code change since their previous release; the new major version only raises the Python floor and, for the ones that depend on it, the rpaframework-core floor.

Robocorp Windows and Robocorp Excel: Python 3.11 and pillow 13

robocorp-windows 2.0.0 and robocorp-excel 0.6.0 now require Python 3.11 or newer and pillow 13.0.0 or newer (#498). Pillow 13 fixes 41 advisories reported against the previous lock files, five of them CRITICAL: heap buffer overflows in the JPEG, FlashPix and TIFF decoders, stale native storage reuse in the multi-frame loaders and argument injection in the Ghostscript call. Pillow 13 only supports Python 3.11 and newer, and Python 3.10 reached end of life in October 2026, so both packages raise their Python floor and get a breaking version bump. Nothing changes in the libraries themselves.

On Python 3.10, pip install robocorp-windows keeps resolving to 1.1.3 and robocorp-excel to 0.5.1. If something else in your environment pins pillow below 13, pip will tell you when you upgrade.

Robocorp Log

robocorp-log 3.1.7 rebuilds the React application that renders log.html with vite 6.4.5 (CVE-2026-118662, server.fs.deny bypassed with query strings in the development server) and minimatch 11 (CVE-2026-118764, denial of service through glob-parts amplification). Both are build-time dependencies and do not end up in the generated log, so nothing changes in how you write logs.

The one remaining advisory in the repository, deepmerge (CVE-2026-93753, low), has no fixed release yet. It is a test-time dependency of the viewer build, pulled in by jest, and never ships to users.

Certificates

certifi 2026.10.18 and newer removes emSign root certificates whose intermediate CA keys were compromised. certifi is a transitive runtime dependency through requests and has no version floor in these packages, so every fresh install already receives the current release; the development lock files of robocorp-http, robocorp-storage, robocorp-vault, robocorp-workitems and the meta package were refreshed to 2026.10.23 without a release.

Upgrading

robocorp 3.1.7 pins the new robocorp-log, so upgrading the meta package is enough for it:

robocorp-windows and robocorp-excel are not part of the meta package; upgrade them separately if you use them, on Python 3.11 or newer:

Released packages

• package robocorp 3.1.7 (meta package)
• package robocorp-log 3.1.7
• package robocorp-windows 2.0.0
• package robocorp-excel 0.6.0

Fixes

• Fixed downloading the demo worker on Windows, which failed with an "Invalid URL" error.
• Fixed an "Unexpected end of JSON input" error when generating a report.
• Fixed View Application Log... and the worker log buttons doing nothing on Windows.
• Explore Changelog now opens the Setup Utility release notes.

Download from here and check our documentation here.

Fixes

• Fixed enabling the shared environment, both for the machine and for Windows workers. If you enabled it with an earlier version, enable it again after updating.

Download from here and check our documentation here.

Security update for the eMudhra CA compromise

Cloud Worker (Debian 12 bookworm) 2026-10-28 is now available in Control Room. It is a security release for the eMudhra intermediate CA compromise disclosed on 20 October 2026. Every part of the image that checks TLS certificates now rejects the compromised certificates:

• Operating system certificate store. The Debian ca-certificates update removes the affected roots, emSign ECC Root CA - G3 and Comodo AAA Certificate Services. Tools that use the system store, such as curl, OpenSSL, Java and Python with truststore, reject the compromised chains.
• Workforce Agent Core v8.1.1 and RCC v21.4.0. The agent's own connections, and the uv installer RCC uses to build environments, no longer trust the compromised certificates. See the Agent Core v8.1.1 and RCC v21.4.0 release notes.
• Chromium. The system Chromium uses its own certificate store, not the operating system's. The image configures it to distrust emSign ECC Root CA - G3, so automations that drive the system browser reject the compromised chains too.

The image also includes the latest Debian package updates.

Your automation code does not need changes. Packages in your robot's own environment, such as pip and certifi, come from your conda.yaml. If you pin old versions there, update them; see the Python packaging guidance.

Which steps receive the update

Cloud Worker (Debian 12 bookworm) auto-update now points to the 2026-10-28 image, replacing 2026-10-01. Steps using this option receive the new container on their next run.

Steps using a dated image keep that image. To update them, select Cloud Worker (Debian 12 bookworm) 2026-10-28 in the process step configuration. We recommend this for every step, because older images still trust the compromised certificates.

See Robocorp-Hosted Cloud Worker for details on dated and auto-update images.

What's new

This is a security release in response to the eMudhra intermediate CA compromise. The Setup Utility, the RCC it runs and the Windows service helper it installs all make their own HTTPS connections. All three are updated so that none of them trusts the compromised certificates.

• Upgraded RCC to v21.4.0. See the RCC v21.4.0 release note for details, including guidance for custom CA bundles.
• Updated to Electron 44.9.3, which blocks the compromised certificates for the application's own connections, including update checks.
• Windows service helper updated to 1.24.1. See the Service Helper v1.24.1 release note.
• Updated dependencies, including security fixes.
• The speed test's Engage button is now called Start.

There are no other changes in behavior. We recommend updating. From v1.10.1 onwards the Setup Utility updates itself automatically. If you are on v1.9.0, v1.9.1 or v1.10.0, install this version manually; see the v1.10.1 release note.

Download from here and check our documentation here.

What's new

Service Helper v1.24.1.

• Updated RCC to v21.4.0, the security release for the eMudhra intermediate CA compromise. RCC now runs on Go 1.26.10 and embeds uv 0.13.4, so neither RCC nor the package installer it runs trusts the compromised certificates. See the RCC v21.4.0 release note for details.
• Updated the bundled Node.js runtime to v24.22.1, which no longer trusts the compromised eMudhra certificates for the connections the executable makes itself.
• Updated dependencies, clearing all CVE advisories.

You can download the latest Service Helper here.

RCC v21.4.0 is a security release in response to the eMudhra intermediate CA compromise disclosed on 20 October 2026. The private keys of several eMudhra intermediate certificates were exposed. A TLS client that still trusts those intermediates can have its connections intercepted, including package downloads from PyPI and conda channels.

Browsers and operating systems have already blocked these intermediates. Tools that ship their own certificate handling, such as RCC and the uv installer it embeds, need their own updates. This release provides them.

We recommend upgrading. There are no functional changes and no breaking changes, so upgrading is a straight swap.

What changed

• Go 1.26.10. RCC's own HTTPS connections now reject the compromised intermediates, even when their root certificate is trusted by the system store or by a ca-bundle.pem in your RCC profile.
• Embedded uv 0.13.4 (GHSA-hq85-5cpj-mr62). uv uses its own built-in root certificates rather than the operating system's, so OS certificate updates did not protect it. uv 0.13.4 updates those built-in certificates.

The first environment build after upgrading may take longer than usual. uv 0.13 uses a new cache format, so it downloads packages again once.

If you use a custom CA bundle

If your RCC profile provides a ca-bundle.pem, RCC passes it to the tools it runs, including uv, pip and Node.js (through SSL_CERT_FILE, REQUESTS_CA_BUNDLE, CURL_CA_BUNDLE and NODE_EXTRA_CA_CERTS). Those tools trust every certificate in that bundle. Make sure your bundle does not contain the affected roots, emSign ECC Root CA - G3 and Comodo AAA Certificate Services, unless your organization needs them. If it does, regenerate it from an up-to-date source.

Your automation code does not need changes for this incident. Python packages in your robot's environment, such as certifi and pip, have their own fixes; see the Python packaging guidance.

Getting v21.4.0

Signed and pre-built executables are available directly:

• Windows — rcc.exe
• macOS (Apple Silicon) — rcc
• Linux — rcc

macOS and Windows builds are code-signed, and the macOS build is notarized. RCC supports macOS on Apple Silicon only; Intel builds were discontinued in v21.0.0.

To check which versions you have, run rcc version and rcc configure diagnostics. The diagnostics output lists the embedded uv and micromamba versions. To test whether your network path rejects the compromised certificates, run rcc configure tlsprobe dv-g3b-noct-emudhra.we-have-a-problem.com:443. It should report a verification failure.

The complete changelog ships inside the executable itself. Run rcc docs changelog to read the full list of changes for the version you have installed.

What's new

Workforce Agent Core v8.1.1.

• Updated RCC to v21.4.0, the security release for the eMudhra intermediate CA compromise. RCC now runs on Go 1.26.10 and embeds uv 0.13.4, so neither RCC nor the package installer it runs trusts the compromised certificates. See the RCC v21.4.0 release note for details, including guidance for custom CA bundles.
• Updated the bundled Node.js runtime to v24.22.1, which no longer trusts the compromised eMudhra certificates for the connections the executable makes itself.
• Updated dependencies, including security fixes.

There are no changes in behavior, and system requirements are unchanged. We recommend updating self-hosted workers to this version.

You can find the detailed changelog for Workforce Agent Core here.

Robocorp Log

robocorp-log 3.1.6 rebuilds the React application that renders log.html with dompurify 3.4.17 (#497). The previous bundle carried 3.4.1, which has since accumulated eleven advisories, among them CVE-2026-49458, CVE-2026-49978, CVE-2026-65898 and CVE-2026-65902. DOMPurify is what sanitises the HTML you pass to log.html() before it is shown in the viewer, so a log file produced by this version carries the fixed sanitiser.

The build tooling for the viewer was refreshed in the same change (vite 6.4.4, handlebars 4.7.10, js-yaml, postcss, browserslist and others). Those are build-time only and do not end up in the generated log.

Nothing changes in how you write logs:

Robocorp Windows and Robocorp Excel

robocorp-windows 1.1.3 and robocorp-excel 0.5.1 raise their pillow requirement to 12.3.0 or newer (#496). Pillow 12.3.0 fixes a run of image-decoding advisories, including CVE-2026-59205 (heap out-of-bounds write in ImageCmsTransform.apply()), CVE-2026-54058 (out-of-bounds read through a controlled row stride) and several missing decompression-bomb checks in the font and GD loaders (CVE-2026-54059, CVE-2026-54060, CVE-2026-55379, CVE-2026-55380).

Both packages already required Python 3.10, which is also Pillow 12.3's minimum, so the new floor does not change which Python versions are supported. If something else in your environment pins an older Pillow, pip will tell you when you upgrade.

Robocorp Vault

robocorp-vault 1.4.2 raises its cryptography requirement to 50.0.0 or newer (#496). That version ships wheels with a patched OpenSSL (GHSA-537c-gmf6-5ccf) and fixes CVE-2026-69247, CVE-2026-69248 and CVE-2026-69249 in certificate verification and PKCS#7 handling.

Upgrading

robocorp 3.1.6 pins the new robocorp-log and robocorp-vault, so upgrading the meta package is enough for those two:

robocorp-windows and robocorp-excel are not part of the meta package; upgrade them separately if you use them:

Released packages

• package robocorp 3.1.6 (meta package)
• package robocorp-log 3.1.6
• package robocorp-windows 1.1.3
• package robocorp-excel 0.5.1
• package robocorp-vault 1.4.2

Python 3.13 and 3.14 support

• rpaframework can now be installed on Python 3.13 and 3.14 (#1351, fixes #1348, contributed by @mikemikimike). The package previously declared <3.14 as its supported Python range, so pip install rpaframework on Python 3.14 fell back to an old release and failed while building its dependencies. The supported range is now >=3.10.

• The rpa-crypto command-line tool no longer uses argparse.FileType, which is deprecated in Python 3.14. Reading from standard input and writing to standard output work as before. Two details changed: the output file is now created only when the command succeeds, and a missing input file is reported as a command failure instead of an argument error.

Security fixes

• Dependency bumps (#1355):

  • PyJWT ≥2.14.0 — CRITICAL, decode() options-dict mutation enabling a silent claim-verification bypass (CVE-2026-103001); HIGH, ReDoS in is_pem_format (CVE-2026-102270); MEDIUM, uncaught RecursionError on deeply nested token headers (CVE-2026-102265), in rpaframework
  • pypdf ≥6.19.0 — HIGH, long runtimes with a large number of embedded files (CVE-2026-102999), in rpaframework-pdf
  • urllib3 ≥2.8.0 — HIGH, infinite loop in chunked deflate streaming (CVE-2026-97688), in rpaframework-aws
  • anyio ≥4.14.2 — CRITICAL, TLS certificate spoofing via IDNA 2003 host name encoding in TLSStream (CVE-2026-63374), and soupsieve ≥2.9.0 — HIGH, polynomial-time ReDoS in selector parsing (CVE-2026-86000), in the packages' development lock files

• rpaframework now requires rpaframework-pdf ≥11.0.3, so upgrading rpaframework on an existing installation also brings in the patched pypdf (#1359).

• Known limitation: rpaframework still installs oauthlib 3.x. The two current oauthlib advisories (CVE-2026-49265 and CVE-2026-49264) are fixed only in oauthlib 4.0.0, which tweepy — a dependency of RPA.Twitter — does not allow yet. Both advisories concern code that runs on an OAuth provider's side (the PKCE check at the token endpoint and the JSONP option of the revocation endpoint). The RPA Framework libraries use oauthlib only as a client, so that code is not reached, but a tool such as pip-audit will still report the package.

Fixes and improvements

• rpaframework-recognition: Fixed OCR text search failing with a bare AssertionError when Tesseract reported a blank word before the end of a line of text (#1354). In RPA.Desktop this made ocr: locators fail immediately, so Wait For Element gave up on the first attempt instead of retrying until its timeout:

• RPA.Email.ImapSmtp: Fixed LookupError: unknown encoding: None when reading a multipart message that has a text part without a charset, which made keywords such as List Messages fail (#1356, fixes #1086). Such parts are now decoded with the library's default encoding, and parts that are neither text nor attachments no longer end up in the message body.

• RPA.Excel.Files: Auto Size Columns now sets the column width from the longest text in each column (#1356, fixes #1104). Previously it only flagged the columns as auto sized, which left the widths unchanged:

The width is estimated from the length of the text, so cells with non-default fonts or number formats can still need a manual width.

Released packages

• package rpaframework 33.0.2
• package rpaframework-pdf 11.0.3
• package rpaframework-aws 8.0.2
• package rpaframework-recognition 8.0.3

Debian package updates

Cloud Worker (Debian 12 bookworm) 2026-10-01 is now available in Control Room. This release contains only package updates in the Debian base image.

Which steps receive the update

Cloud Worker (Debian 12 bookworm) auto-update now points to the 2026-10-01 image, replacing 2026-09-07. Steps using this option receive the new container on their next run.

Steps using a dated image keep that image. To update them, select Cloud Worker (Debian 12 bookworm) 2026-10-01 in the process step configuration.

See Robocorp-Hosted Cloud Worker for details on dated and auto-update images.

Memory growth in output redaction

robocorp-log redacts sensitive values from the log output. Every value registered for hiding, whether explicitly through hide_from_output() or automatically because it was assigned to a variable with a sensitive-looking name such as password, is added to a single regular expression that is rebuilt each time a new value arrives.

Rebuilding that expression had a hidden cost (#489, fixed in #491). Each rebuild produced a new, slightly longer pattern, and CPython's regular expression cache kept the last several hundred of them alive. In a long-running process that registers a new sensitive value per processed record, the retained patterns grew without bound. One reported batch job reached roughly 13 GB of memory over seven hours before ending with:

Redaction itself was never at risk: every registered value was still hidden from the output. The defect only affected memory use and, before that, throughput.

The active pattern is now compiled outside the process-wide cache, so only the current version is kept. Measured with the reproduction from the issue, registering 2,400 values took about 34 MB of memory instead of roughly 800 MB, with redaction output unchanged.

Who should upgrade

You are most likely affected if all of the following apply:

• The automation runs for hours in one process, for example a batch loop over many records.
• A sensitive-looking variable name, or a pattern added with add_sensitive_variable_name_pattern(), matches a value that changes on every iteration.
• Memory use climbs steadily during the run, or the run slows down over time.

If you saw MemoryError raised from robocorp/log/_log_redacter.py, this release is the fix.

Upgrading

robocorp 3.1.4 pulls in the fixed robocorp-log automatically, so installing the meta package is enough:

If you depend on robocorp-log directly, upgrade it to 3.1.5.

Released packages

• package robocorp 3.1.4 (meta package)
• package robocorp-log 3.1.5

What changed

Several longstanding bugs in GitLab integrations and task package linking surfaced recently. Affected packages could stop updating after repository pushes or fail to show their GitLab deployment details.

We improved the robustness of GitLab linking and reconnection to address these problems. Existing links can resume updating after their GitLab connection is restored, and new links use the correct integration.

What you need to do

If your GitLab-linked packages are updating normally, no action is needed. If Control Room shows your GitLab integration as inactive, select Reconnect in your organization settings. If a task package missed updates or still does not update after reconnecting, re-link that package to its GitLab repository. Re-linking fetches the current revision; future pushes can then update the package again.

Manual upgrade required from v1.9.0, v1.9.1 and v1.10.0

Automatic updates are broken in those three versions, so they cannot update themselves to v1.10.1. If you are running any of them, download and install v1.10.1 by hand from the download page. You only have to do this once — automatic updates work normally again from v1.10.1 onwards.

Version v1.8.0 and older are not affected and will update automatically.

To check which version you are on, open the settings menu in the Setup Utility and choose Check for Updates.

Check your profiles after upgrading

The same fault also sent profiles to the wrong location, so profiles imported or switched through v1.9.0, v1.9.1 or v1.10.0 did not reach the workers the Setup Utility manages. Once you are on v1.10.1, check your profile list and import again any that are missing.

Download from here and check our documentation here.

What's new

This is a security and maintenance release.

• All high and critical CVEs in the application's dependencies are cleared.
• Updated to Electron 44, which brings a newer Chromium and Node 24 runtime.
• Upgraded RCC to v21.3.0.
• Windows service helper updated to 1.24.0.

If you are on v1.9.0 or newer, read this before upgrading

Automatic updates do not work in v1.9.0, v1.9.1 or this release. You need to install v1.10.1 manually — see the v1.10.1 release note for what happened and what to do.

Download from here and check our documentation here.

What's new

Service Helper v1.24.0.

• The bundled runtime has been updated to Node v24.
• Updated RCC to v21.3.0.
• Updated dependencies, clearing all high and critical CVE advisories.

You can download the latest Service Helper here.

How it used to work

A step configuration offered four Cloud Worker options:

• Cloud Worker — the default.
• Cloud Worker (early access) — the next version, for testing before it became the default.
• Cloud Worker (previous) — the version that was the default before.
• Cloud Worker (Ubuntu 18.04 legacy) — the old Ubuntu container.

Cloud Worker was updated to a newer container from time to time. (previous) kept the container it replaced.

None of the four options let you select an exact container. We controlled what each name pointed to, and we could change it. If a customer needed a fixed container, we configured it manually for that workspace. These manual workarounds show that the model did not work, so we are replacing it.

The names also gave you no information. They did not show the Linux distribution or the build date, and (early access) and (previous) pointed to different containers at different times.

What changes

Each step now uses one of two kinds of option.

• A specific version. The name gives the distribution and the build date, for example Cloud Worker (Debian 12 bookworm) 2026-09-08. This container never changes.
• The automatically updating version. The name ends in auto-update instead of a date, for example Cloud Worker (Debian 12 bookworm) auto-update. When we release a new Cloud Worker for that distribution, we point this option to it. Your steps use the new container on their next run.

Each distribution has one auto-update option, and it only moves within that distribution. A new distribution is added as a new option. We never apply it to an existing selection.

We normally set the auto-update option to the latest available image. This is a guideline, not a fixed rule.

We plan to release a new Cloud Worker about once a month. This is a target, not a commitment.

What this means for your steps

Nothing changes. Your steps use the same container as before. Only the name is different.

There is one exception. Cloud Worker (early access) becomes the auto-update option, so it moves to the latest container. This is the update that option was designed to receive.

The Extended variant is removed. The standard Cloud Worker now contains everything the variant added, including LibreOffice.

No action is required. When you next work on your process configurations, check which Cloud Worker each step uses. The name shows the build date, so you can see if it is old.

See Robocorp-Hosted Cloud Worker for details.