OpenClaw Ships 2026.10.9 and 2026.9.36, but the Codex 0.164.0 Upgrade Waits for the 2026.10.10 Stable Candidate
The 2026.10.9 security patch, extended-stable 2026.9.36 and 2026.10.10-beta.5 all shipped Thursday, but each still bundles Codex 0.160.0. Also: why the release counts say 38 and 48 pull requests, a check of the 591-advisory claim, Multiplayer OpenClaw at GitHub Universe, cross-device Stop on main, and the Graincrawl skill.
All Three Patch Releases Are Now Tagged
Yesterday's open question is settled. The three patch lines we found waiting on release branches on Thursday morning all shipped within about 12 hours. The OpenClaw 2026.10.9 release on GitHub was published at 8:54 AM Pacific on Thursday, eight minutes after the npm package went live. The 2026.9.36 extended-stable release on GitHub followed at 1:19 PM, and the 2026.10.10-beta.5 prerelease on GitHub at 8:57 PM. The npm channels now read latest 2026.10.9, extended-stable 2026.9.36 and beta 2026.10.10-beta.5.
The official 2026.10.9 release notes on docs.openclaw.ai label it a security release that "adds remediations for vulnerable dependencies and repairs credential handling and workspace restrictions," and say plainly: "This is a patch release with no new features." The dependency fixes match what we reported from the draft: fast-uri 4.2.3 for MCP tool schemas, MSAL Node 7.1.1 scoped to the affected Teams apps and Azure Identity versions, Nodemailer 10.1.4 for IMAP sender checks, and early rejection of oversized collections in Canvas/A2UI and Discord Activity. The final page adds detail the draft lacked. The IMAP flaw let a spoofed message pass when a trusted address was hidden inside nested comments in its From header, and MCP command-line inspection now shows redaction placeholders where it used to print recognized credentials.
Two user-facing repairs stand out beyond security. New ACP sessions now run tools in the project folder you asked for, including after a session reset, instead of silently using the default workspace; the notes say to use an absolute folder path on the Gateway host. And a failed update of a Git checkout now preserves detected edits and untracked files during rollback. If rollback is refused, the notes tell you to save your changes before following the printed recovery commands.
38 Pull Requests or 48? Both Numbers Are Official
The official @openclaw announcement of 2026.10.9 on X, posted at 2:08 PM Pacific, says "38 PRs · 22 contributors," and the docs page gives the same scale: "38 pull requests, 8 direct commits, and 22 contributors." The GitHub release body counts differently. Its audited contribution record says it covers "48 unique PRs" between 2026.10.8 and the release commit, and lists every one. The docs page explains the gap: its count "includes source work brought in through backports, without counting the backport wrappers twice." The GitHub record counts the backport pull requests themselves, which is why it runs higher.
If you track OpenClaw releases in a spreadsheet or a changelog bot, pick one counting rule and say which one you use. The docs figure removes duplicate backport work, so it is the better measure of what changed. The GitHub figure is the better audit trail, because every listed pull request number can be checked against the code.
Extended-Stable 2026.9.36 Lands, and Only the Beta Relaxes the Node Floor
The extended-stable release, which the project calls "our current equivalent to LTS," carries the same workspace and dependency fixes as 2026.10.9, plus fixes of its own. Name-keyed Microsoft Teams allowlist entries that don't resolve now grant nothing, the eMudhra certificate trust remediation from the October 28 backport is applied, and comparison prose after emoji and other astral characters is no longer stripped from outbound replies. Its record lists 28 unique pull requests.
The release packages differ on Node. The 2026.10.9 and 2026.9.36 packages both still declare >=24.22.1 <25 || >=26.12.1, the hard floor introduced after the eMudhra key compromise. Only 2026.10.10-beta.5 declares the looser >=24.16.0 <25 || >=26.1.0, so the two stable lines still refuse older Node 24 builds. The beta's range reflects pull request #186589 keeping updates working below the recommended Node security patches, which turned the newer Node versions into a warning instead of a requirement. The same pull request still urges you to "Upgrade Node promptly," because those Node patches reject the compromised eMudhra keys.
Codex 0.164.0 Misses All Three Releases
After the 2026.10.9 announcement, a user on X asked OpenClaw to ship Codex 0.164.0, arguing that 2026.10.9 still bundles Codex 0.160.0. The package files confirm the version part. The managed Codex extension in the 2026.10.9, 2026.9.36 and 2026.10.10-beta.5 tags all pin @openai/codex 0.160.0. Main moved to 0.164.0 on October 25 via pull request #181823 updating the managed Codex runtime to 0.164.0, which also accepts Codex's new "API key configured" sign-in wording.
The upgrade is now on its way to a stable release. The release/2026.10.10 branch has moved from beta numbering to version 2026.10.10 and pins Codex 0.164.0. Pull request #188157 clarifying the Codex 0.164.0 CLI in the 2026.10.10 notes, merged at 12:21 AM Pacific on Friday, says "the qualified stable candidate carries the managed Codex CLI at 0.164.0" and also "Publication is not authorized by this PR." As of about 6:30 AM Pacific there was no 2026.10.10 tag, and its docs release page returned "not found."
We couldn't confirm the eMudhra part of the request. The OpenAI Codex 0.164.0 release notes on GitHub don't mention eMudhra. They do list a change updating the rustls-webpki and webpki-roots lockfile versions, and OpenClaw's draft 2026.10.10 notes don't link the Codex upgrade to the certificate incident either. Treat the security reason as unverified.
Bundled tools have their own version numbers, and an OpenClaw release can be current while carrying an older one. If you run the Codex runtime through OpenClaw, check the pinned Codex version on each upgrade instead of assuming it matches upstream, and plan to move once a tagged 2026.10.10 includes 0.164.0. Don't pull the release branch early.
The 591 Advisories Claim Checks Out, With a Caveat on Scope
A claim on X says OpenClaw collected 591 security advisories this year, more than the whole Rust ecosystem. On October 27 the testing site TriedAgents published TriedAgents' reproduction of the OpenClaw advisory count, which found the number held up. We reran the queries this morning. The OSV vulnerability database entry list for the npm openclaw package returns 591 records through its API, every one published in 2026. Of those, 510 were published between February and April. By the severity OSV records, 20 are critical, 216 high, 301 moderate and 54 low.
The repository's own published security advisories for openclaw/openclaw on GitHub number 722, all from 2026. GitHub rates 14 critical, 249 high, 390 medium and 69 low. The two lists measure different things: one is advisories filed against the npm package, the other is everything the project published for the repository. They don't agree on timing either. The repository list shows 75 advisories published in September, while the OSV npm records show none that month. For Rust, GitHub's reviewed advisory database returned 547 Rust-ecosystem entries published in 2026 at our check, up from the 536 TriedAgents counted three days earlier. Either way, 591 is higher.
A high advisory count says as much about disclosure practice as about code quality. A project that files every fix publicly will look worse in raw counts than one that patches quietly. What matters to an operator is how quickly fixes reach the release you run. Check each advisory's patched version against your install, and stay on a supported line such as 2026.10.9 or extended-stable 2026.9.36 rather than an older build.
Multiplayer OpenClaw Goes to GitHub Universe
OpenClaw had a booth at GitHub Universe on Thursday. The official @openclaw post inviting GitHub Universe visitors to the OpenClaw booth asked them to "check out Multiplayer OpenClaw in action." The name is about to become official in the docs. Pull request #187963 consolidating the team docs into one Multiplayer page, opened late Thursday afternoon Pacific and still open, merges the current Team setup and Deploy a team server guides into a single page at /start/multiplayer. It frames OpenClaw as either a "personal claw" or a "multiplayer claw," keeps the old URLs as redirects, and leaves the setup flow unchanged.
What multiplayer means today is in the OpenClaw team setup guide: one Gateway the whole team uses, with a bot in your existing workspace chat, shared sessions everyone can open and steer in the Control UI, and roles that limit what each person can do. The guide says team operation "is configuration, not a separate edition." Shared sessions record an immutable creator, an assignable owner and everyone who prompted, and presence shows who is viewing and typing.
Treat a shared Gateway as one trust boundary
Before inviting a team, read the trust section of the OpenClaw team setup guide. It says a Gateway "is one trust domain": everyone who can message a tool-enabled agent shares that agent's delegated tool authority, and everyone with operator access shares one control plane. Ownership, presence and roles are "collaboration guardrails inside the boundary, not isolation between adversaries."
- Serving mutually untrusted people or organizations? The guide's answer is one Gateway per tenant, not one shared Gateway with roles.
- Prefer identity-backed access through a tailnet with Tailscale Serve or an identity-aware proxy such as Cloudflare Access. A shared token or password puts everyone on one owner profile, so you lose per-person attribution.
- Keep the group defaults: per-room allowlists, replies only when mentioned, and pairing codes for DMs. For broad or public rooms, add sender allowlists as the guide recommends.
On Main: Stop From Any Device, a Watch Assistant and Granola Meetings
About 370 pull requests merged across main and the release branches between Thursday and Friday mornings. None of these is in a release yet. Three are worth knowing about:
- Pull request #187408 letting you stop your own work across devices, merged at 8:16 AM Pacific on Thursday, fixes Stop requests that were rejected as unauthorized when sent from a second browser. The same signed-in person can now cancel work they started elsewhere, while assigning someone else as conversation owner "does not give that person cancellation authority over the original initiator's work."
- Pull request #187587 making OpenClaw a Wear OS default assistant, merged Thursday evening, lists the watch app under Wear OS's default digital assistant setting. The assistant button opens the Talk page, but the user still has to tap to start, so "the mic never opens without a direct tap." It adds no new permissions.
- Pull request #187659 adding a Learn from Granola scribe to Knowledge ingests Granola meetings once or on a weekday schedule through the Granola plugin, replacing what the pull request calls a "hand-rolled automation" built on a Granola API key and Python scripts.
The cross-device Stop fix is the one teams will feel first. When several people share a session, someone needs to be able to halt runaway work quickly, and the rule here is narrow: the person who started a run can stop it from anywhere, while a new owner cannot cancel it for them. That's the right default for a shared Gateway.
Skill Card: Graincrawl Keeps Granola Notes Local and Read-Only
openclaw/graincrawl for searching Granola notes and transcripts
If the new Granola scribe interests you but you'd rather keep meeting data on your own machine, there is an official alternative. The Graincrawl skill listing on ClawHub, published by the OpenClaw organization, is at version 1.0.1 with 2,220 downloads and 16 installs, and ClawHub's moderation verdict is clean. The skill tells the agent to check freshness with graincrawl doctor --json and graincrawl status --json, to sync only when data is stale or you ask, and to use read-only SQL for exact counts.
The graincrawl repository under the OpenClaw organization, MIT-licensed with v0.4.8 released October 26 Pacific, builds a private local SQLite archive of Granola notes, transcripts, panels and people. Its README says every source is "read-only against Granola" and that graincrawl writes only to its own config, cache and archive. The official public API source needs an explicit opt-in. Two cautions from the README: Granola 7.427 and later can keep its encryption key in a Keychain item graincrawl can't read, which graincrawl doctor detects, and graincrawl import --replace performs an exact restore that removes rows missing from the snapshot.
Meeting transcripts are untrusted input that can carry instructions from anyone who spoke in the meeting. Graincrawl is a good fit for a reader agent because it can't write back to Granola and its SQL is read-only. Keep that agent away from send or exec tools, and pass anything it finds to a separate agent that acts only after you approve.
Rolling 2026.10.9 out to a team Gateway?
SEN-X helps teams plan OpenClaw upgrades across stable and extended-stable lines, check bundled runtimes and Node floors, and set up shared Gateways with the right trust boundaries.
Contact SEN-X →