AI Wiki

Explore AI Wiki

Citation and evidence

OpenWorker

20 min full readUpdated 40 references

This article's verification

Report a problem with this article

More

Use this article

Raw MarkdownExplore connections

Improve this page

Suggest editRevision historyDiscussion

Browse categories

AI AgentsAI Tools & ProductsDeveloper ToolsOpen Source AI

Cite this article

OpenWorker is an open-source, local-first desktop AI agent announced by Andrew Ng. It combines a desktop interface with a local agent server that can work with files, a terminal, and connected services. The project is designed to return a completed artifact or carry out an approved action, rather than limit its output to a chat response.[1][2][4][12] Ng has described OpenWorker as joint work with Rohit Prasad, his collaborator on the aisuite library that the agent engine is built on.[1][13][31]

OpenWorker remains in open beta. Its v0.2 series introduced reusable skills, memory, an optional reviewer for tool approvals, and three security-focused coworkers.[4][5][6] As of September 30, 2026, v0.2.1 (August 25) was still the latest tagged release and the version served by the app's auto-update feed, while the main branch had moved on to version 0.2.3.[27][28][29] In late September the developers merged optional sandboxing into the main branch: an agent's shell commands and file tools can run inside an NVIDIA OpenShell container, the sandbox built into macOS, or a restricted Windows account. Ng presented the OpenShell work on September 28, the day NVIDIA launched its Open Agent Safety Platform, writing that OpenWorker "will support" sandboxed commands; the code had not reached a tagged release by the end of the month.[13][16][19][22][27]

Key facts

FieldDetail
ProjectOpenWorker[2][4]
Repositoryandrewyng/openworker[4]
Announced byAndrew Ng[1][12]
DevelopersAndrew Ng and Rohit Prasad, per Ng; Rohit Prasad and Devika Verma are the largest code contributors[1][13][34]
StatusOpen beta[4][30]
Latest tagged releasev0.2.1, published August 25, 2026; still the latest release and auto-update version on September 30, 2026[6][27][28]
Main branch (unreleased)Version 0.2.3 in the app configuration on September 30, 2026[29]
PlatformsDesktop builds for macOS 12 or later (Apple Silicon, and Intel from v0.2.0) and Windows 10/11 x64, whose builds are not yet code-signed[5][30]
Application designTauri desktop shell and React interface over a local Python agent server[4]
Model accessUser-supplied provider keys, open-weight providers, or local inference through Ollama[2][4]
ExtensibilityMore than 25 documented integrations, local tools, and MCP servers[4]
SandboxingOptional, set per machine: NVIDIA OpenShell (Linux, or a Mac with Docker Desktop), the macOS built-in sandbox, or a hidden Windows account; merged to the main branch September 24-29, 2026[16][19][22][23][24]
GitHub activity18,371 stars and 2,598 forks on September 30, 2026; repository created July 20, 2026[30]
LicenseMIT License[11]

Expanded article table

Development and releases

Independent reporting described OpenWorker's public release in July 2026 as a desktop agent built around a Tauri and React interface, a Python server, connectors, and a model router. Those architectural details match the current public repository.[4][12]

Version 0.2.0 was published on August 24, 2026. It added instruction packages called skills, project-bound memory, guided setup for the Model Context Protocol, an auto-approve reviewer mode, and three security coworkers. Its release notes also report fixes for scheduled-task handling across daylight-saving changes and weekday rules, approval gating for Git clone and pull operations, private permissions for secrets files, pinned web-fetch connections, updated MCP dependencies, and other workspace-trust and approval fixes.[5]

Version 0.2.1 followed on August 25. It added Ox Alpha to the model picker through OpenRouter. The release page identified v0.2.1 as the latest tagged version when checked on August 27.[6]

No further version had been tagged by September 30, 2026. The release list still ended at v0.2.1, and the update manifest the desktop app checks, at download.openworker.com, still pointed to the v0.2.1 builds.[27][28] Development continued on the main branch, where the Tauri configuration and the Python package both carried version 0.2.3.[29] Pull requests merged there after v0.2.1 include the following:

Merged (2026)Pull requestChange, as described in the pull request
August 29#127GUI internationalization with English and Simplified Chinese[35]
September 3#598A revised MCP permission model with an "EXTERNAL" floor, durable per-tool trust, and fixed approval cards[36]
September 18#672Remote machines: sessions can run on another computer where OpenWorker is installed and be managed from the same app; agent-team staffing cards with per-worker connector and model grants[37]
September 19#673Command-line openworker join, up, and machine commands, with the package published as openworker[38]
September 22#679A Team View and hardened agent-team coordination[39]
September 24-29#684, #685, #699, #700, #701, #704Sandboxing, described in Sandboxing and NVIDIA OpenShell[16][17][18][19][20][21]
September 29#705A Linux build packaged as one program that needs no separate Python installation[40]

Expanded article table

Because none of this work was in a tagged release on September 30, it was available to people running OpenWorker from source rather than to users of the packaged desktop app.[27][28]

Architecture and local-first design

The desktop application uses a Tauri native shell with a React interface. The shell supervises a Python server running on the same computer. The repository places the agent engine, provider adapters, connectors, MCP client, memory, and automation code in that server. OpenWorker builds this engine on aisuite, a Python library for accessing multiple model providers through a common interface.[4]

This arrangement supports computer use without requiring OpenWorker to operate a hosted agent loop. The project's privacy policy says that conversations, prompts, generated files, model keys, and connector tokens are stored on the user's device rather than on OpenWorker's servers. One-click connector setup can use an optional cloud service for sign-in and OAuth handshakes, while manually supplied credentials can be used without an OpenWorker account.[3][4]

Local-first does not mean that every task remains on the device. The privacy policy says that conversation content goes directly from the computer to the configured cloud model provider. Content from connected services can also be sent to that provider when needed for a requested task. Real-time connector events may pass through an OpenWorker relay for delivery, and the policy says use of each connected service remains governed by that service's own terms. These are statements in the project's policy, not findings from an independent privacy audit.[3]

Local inference through Ollama avoids sending model prompts to a cloud model provider. A task can still communicate with remote services if it uses email, Slack, GitHub, a web tool, or another networked connector.[2][3][4]

Models and connectors

The current README lists native or supported access to OpenAI, Anthropic, Google Gemini, BytePlus Ark, Volcengine Ark Agent Plan, Inkling, GLM, DeepSeek, Kimi, Qwen, MiniMax, Mistral, and Grok. It also lists Together and Fireworks for open-weight models and Ollama for models run locally. The project maintains a curated list of models its developers have checked for tool-calling work, while allowing unlisted model strings at the user's risk.[4] Ng's August 25 post also said users could run open-weight models fully locally, use a ChatGPT subscription, or use stealth preview models such as Ox Alpha.[1]

OpenWorker's documentation advertises more than 25 integrations. Examples include GitHub, Slack, Jira, Notion, Linear, HubSpot, Outlook, monday.com, Gmail, and Google Calendar. Local files and the terminal are also tools. MCP servers can add further tools, with approval behavior configured per tool.[2][4]

The privacy policy says connector tokens are stored only on the user's device, and the README places them in the app's local secret store.[3][4] For managed connections, the optional OAuth broker handles the sign-in exchange and passes the token to the device. The policy says the broker does not retain those tokens. This design still depends on the privacy and security behavior of the selected model provider and connected services.[3]

Approvals and scheduled work

Project documentation describes consequential actions such as sending a message, changing a calendar entry, making writes, and running commands as approval-gated. Its control model has several levels: one-time approval, standing rules, configuration allowlists, and an optional model reviewer for routine calls. The README says a set of developer-defined human-only floors remains outside reviewer and bypass approval paths.[4] In late September the README's "Governed by design" section went from three tiers to four, adding "a sandbox for what the agent runs".[4][30]

In auto-approve mode, a reviewer model examines calls that would otherwise request approval. Uncertain calls are sent to the user, and repeated denials can pause the reviewer for the rest of the turn. The documentation calls these verdicts judgments rather than guarantees. It also says that tool-call records preserve whether a call was approved by a user, approved by the reviewer, or denied, together with the recorded reason.[4]

These controls implement a form of human-in-the-loop operation, but the public documentation does not demonstrate that every bypass or prompt injection attempt will be stopped. The project's security policy treats bypasses of human-only floors or approval gates as high-severity vulnerabilities, which defines the intended boundary without independently validating it.[4][10]

OpenWorker can schedule recurring tasks such as briefs or reports. Runs and transcripts appear in the application. The README says unattended runs cannot approve their own blocked actions; requests wait in an inbox for a person. Version 0.2.0 specifically fixed daylight-saving and weekday-rule behavior in scheduled automations.[4][5]

Security coworkers in v0.2

Version 0.2.0 added three specialist configurations for development security. Each is a bundled persona with named tools and workflow instructions. They combine conventional scanners with model-based triage and drafting.[5]

CoworkerDocumented workflowIntended human checkpoint
Security CoworkerRuns Semgrep and Gitleaks when available, reads the surrounding code, classifies findings by reachability and impact, avoids printing secret values, and prepares focused fixes with tests[7]Installing a missing scanner requires approval; fix pull requests are prepared for review rather than merged by the coworker[7]
Cloud Posture CoworkerScans infrastructure code with Trivy or Checkov, uses read-only AWS queries, compares live configuration with Terraform, and drafts changes in code[8]It is instructed not to write to the cloud or run terraform apply; a team reviews and applies the proposed infrastructure change[8]
Dependency Audit CoworkerUses tools such as osv-scanner, npm audit, pip-audit, or Trivy, checks whether vulnerable code is reachable, chooses the smallest closing upgrade, and runs the project's install, build, and tests[9]It prepares focused upgrade pull requests and is instructed never to merge its own; a failing test suite means investigating or reverting rather than handing over a broken upgrade[9]

Expanded article table

The Security Coworker's instructions distinguish scanner output from the model's role. Scanners provide findings; the model reads code context, ranks the findings, drafts fixes, and records which checks could not run. Its secret-scan workflow calls for credential rotation before code removal and prohibits putting secret values in output or pull requests.[7]

The Cloud Posture workflow makes a similar distinction between observation and change. It permits read-only account queries and directs remediation into infrastructure code. The Dependency Audit workflow ranks advisories by documented reachability rather than severity alone and asks for the smallest available upgrade that closes the advisory.[8][9]

These files specify intended behavior, not measured effectiveness. The sources used for this article contain no independent penetration test, certified audit, benchmark of vulnerability-detection coverage, or evaluation of fix quality. Results depend on the selected model, installed scanners, project structure, configuration, credentials, and the quality of human review.[7][8][9]

Sandboxing and NVIDIA OpenShell

Ng's September 28 post

NVIDIA announced the Open Agent Safety Platform on September 28, 2026, pairing its open-source OpenShell agent runtime with a hardware reference design called Sentry.[15] The same day Ng quoted Jensen Huang's launch post and called OpenWorker "our open-source agent harness supporting cybersecurity workflows". He wrote that OpenWorker "is building on Nvidia OpenShell and will support running each agent's commands inside a sandbox."[13][14]

Ng's post described what that sandbox would do. Only the files relevant to a task go in, and secret API keys, the user's web browser login credentials, and the ability to reach arbitrary websites are inaccessible to the agent by default. He wrote that these restrictions are "implemented in deterministic code rather than by prompting an LLM, which can make mistakes or be susceptible to prompt injections", and that all actions are logged for monitoring and audit.[13]

The post opened with Ng's own assessment of the July 2026 OpenAI-Hugging Face agent incident: "The OpenAI-Hugging Face hack was enabled by weak sandboxing." It closed by thanking Huang and saying that OpenWorker, "which @rohitcprasad and I are working on", would "continue to improve security for agents."[13]

NVIDIA's press release does not mention OpenWorker in its text. The partner graphic attached to Huang's launch post, in which he said NVIDIA had introduced the platform "with over 100 industry partners", does include an OpenWorker logo.[14][15]

The collaborator Ng tagged is Rohit Prasad. The X account @rohitcprasad describes itself as "aisuite | OpenWorker | Agent harness" and links to openworker.com, as does the GitHub account rohitprasad15 under the name Rohit Prasad.[32][33] That account was the repository's largest contributor on September 30, 2026, with 324 commits, followed by Devika Verma with 150.[34] Ng had described aisuite in December 2025 as a package "that Rohit Prasad and I have been working on", and his August 25, 2026 post asked readers to follow @rohitcprasad for more frequent OpenWorker updates.[31][1]

What was merged

The first sandbox pull request was merged four days before Ng's post, and work continued after it. The earliest commits in that pull request are dated September 19, 2026.[16]

Merged (2026)Pull requestAuthorWhat it added
September 24#684, "Add support for Sandboxing using NVIDIA OpenShell"Devika VermaAn OpenShell provider with one sandbox per agent, a standard-library tool runner that executes the agent's shell and file tools inside the sandbox, an allow-list network proxy, a macOS sandbox provider, copied credential grants, and a Sandbox settings page; 7,030 lines added across 62 files[16]
September 24#685, "Add docs for OpenShell support"Rohit PrasadThe OpenShell documentation page, a new README tier, and a configuration example[17]
September 28#699Devika VermaGuided OpenShell setup, readiness checks, and switching for sessions already open[18]
September 28#700, "Sandboxing improvements for Windows and Mac"Rohit PrasadA Windows provider that runs commands as a hidden local account, macOS and Windows documentation, and an "open" network profile on every provider[19]
September 29#701, "Simplify the Sandbox settings page."Rohit PrasadA reworked Settings page[20]
September 29#704Rohit PrasadOpenShell clean-up that removes only the sandboxes OpenWorker's own state folder created[21]

Expanded article table

The description of #684 says the sandbox "confines the commands an AI agent runs to the files and network addresses the user has approved, so a compromised or misled agent cannot reach the user's keys, documents or other systems."[16]

How the sandboxes work

The documentation describes three sandbox types. The choice is made per machine, in Settings or in config.toml, and a project's own configuration cannot change it.[22][23]

Sandbox typeWhere it runsMechanismDefault network setting
NVIDIA OpenShellLinux, or a Mac with Docker Desktop; not available on WindowsOne Linux container per agent, built from a pinned base image of about 5 GB. The OpenShell gateway creates the sandbox, applies Landlock, seccomp, and network policy, and writes its own OCSF audit log; a kernel without Landlock refuses to run.[22]Allow list of sites the user ticks, such as GitHub, PyPI, or npm[22]
macOS sandboxmacOS, with nothing to installSeatbelt, the sandbox built into macOS. OpenWorker renders a profile from the session's folders, and the kernel enforces it on every process a command starts.[23]Allow list, enforced through a local proxy that is the only network endpoint the sandbox can reach[23]
Windows sandboxWindows, after a one-time administrator setupA hidden local account that cannot read the user's profile, with file permissions, a Windows Firewall rule, and Windows Filtering Platform filters[24]Open (any site, with files still confined)[24]

Expanded article table

The documentation lists properties common to the design. The agent loop, the model keys, and every connector stay outside the sandbox, which sees only the session's folders at their usual paths. The project describes secrets as "absent, not denied". Each tool result records which enforcement mode produced it, in the tool-call event and in the audit trail. When a machine is set to a sandbox that cannot be used, sessions are refused rather than run unprotected.[22][23] Users can deliberately share a credential, such as SSH keys, a GitHub CLI login, AWS profiles, or a kubectl configuration. An enabled entry is copied into a private home folder that is mounted into the sandbox and deleted with it, and the entry adds the network hosts its tool needs to the allow list.[22]

OpenWorker's documentation and code pin OpenShell 0.0.116, which NVIDIA released on August 28, 2026, as "the release OpenWorker is tested against". A comment in the provider code says the project will keep "one pinned release until NVIDIA ships GA". NVIDIA had already released OpenShell 0.1.0 on September 25 and 0.1.2 on September 28.[22][25][26]

Announced and shipped

Ng's post described the OpenShell support in the future tense. On September 30, 2026, the sandbox code and documentation were in the main branch, but no tagged release contained them and the update feed still served v0.2.1.[13][27][28] Sandboxing is also off until a user turns it on: the documentation says the desktop app "runs commands directly, as it always has, until you turn OpenShell on for the machine."[22] Pull request #700 noted that the packaged Windows build had not yet been exercised with the Windows sandbox.[19]

Ng's summary of the defaults matches the OpenShell and macOS configurations, where the network is limited to an allow list. The Windows sandbox, whose default network profile is open, does not restrict websites or local ports unless the user picks a stricter profile, and it keeps the user's profile out of reach but can still read folders outside the profile, such as D:\work, because Windows lets every local account read them by default.[13][22][23][24] These documents describe the intended design. The sources used for this article include no independent test of the sandboxes.

Open-source status and security policy

OpenWorker is an open-source AI tool published under the MIT License. The license permits use, modification, and redistribution subject to retaining its copyright and permission notice, and it provides the software without warranty.[11]

The repository's security policy covers the desktop app, local server, permission and reviewer flow, audit trail, and the OAuth broker used by managed connectors. It asks researchers to report vulnerabilities privately, supports only the latest release, and states that there is no bug bounty program.[10]

Because the project is an open beta, its documented safeguards should be read as design claims and current implementation goals. Choosing a local model can reduce one external data path, but model choice alone does not remove risks from connectors, third-party MCP servers, local command execution, or incorrect model judgments.[3][4][10] Where a sandbox is enabled, it limits what an agent's commands can reach, but connectors still run in OpenWorker itself, outside every sandbox, with their own tokens.[22]

References

  1. ^1 ^2 ^3 ^4 ^5 ^6Andrew Ng. Post announcing the OpenWorker security-workflow update. X, Aug. 25, 2026. x.com/...2092315079576555806
  2. ^1 ^2 ^3 ^4 ^5OpenWorker. "AI that gets your everyday tasks done." Accessed Aug. 27, 2026. openworker.com
  3. ^1 ^2 ^3 ^4 ^5 ^6OpenWorker. "Privacy Policy." Effective July 17, 2026; accessed Aug. 27, 2026. openworker.com/privacy
  4. ^1 ^2 ^3 ^4 ^5 ^6 ^7 ^8 ^9 ^10 ^11 ^12 ^13 ^14 ^15 ^16 ^17 ^18 ^19 ^20 ^21Andrew Ng. "OpenWorker" repository and README. GitHub, main branch at commit 86c57f0692a5a318e55d1b9e0188d798b9fc5690, accessed Aug. 27, 2026. github.com/...openworker
  5. ^1 ^2 ^3 ^4 ^5OpenWorker. "OpenWorker v0.2.0." GitHub Releases, Aug. 24, 2026. github.com/...v0.2.0
  6. ^1 ^2 ^3OpenWorker. "OpenWorker v0.2.1." GitHub Releases, Aug. 25, 2026. github.com/...v0.2.1
  7. ^1 ^2 ^3 ^4OpenWorker. "Security Coworker" manifest and bundled skills, v0.2.1. GitHub. github.com/...security
  8. ^1 ^2 ^3 ^4OpenWorker. "Cloud Posture Coworker" manifest and bundled skills, v0.2.1. GitHub. github.com/...cloud-posture
  9. ^1 ^2 ^3 ^4OpenWorker. "Dependency Audit Coworker" manifest and bundled skills, v0.2.1. GitHub. github.com/...dep-audit
  10. ^1 ^2 ^3OpenWorker. "Security Policy." GitHub, accessed Aug. 27, 2026. github.com/...SECURITY.md
  11. ^1 ^2Andrew Ng. "MIT License." OpenWorker repository, GitHub, accessed Aug. 27, 2026. github.com/...LICENSE
  12. ^1 ^2 ^3Asif Razzaq. "Andrew Ng Just Released OpenWorker: An Open-Source, Local-First Desktop AI Coworker That Returns Finished Deliverables Instead of Chat." MarkTechPost, July 23, 2026. marktechpost.com/...d-deliverables-instead-of-chat
  13. ^1 ^2 ^3 ^4 ^5 ^6 ^7 ^8Andrew Ng (@AndrewYNg). Post quoting Jensen Huang's Open Agent Safety Platform announcement. X, Sept. 28, 2026. x.com/...2104660347730969087
  14. ^1 ^2Jensen Huang (@JensenHuang). Post announcing the NVIDIA Open Agent Safety Platform, with partner graphic. X, Sept. 28, 2026. x.com/...2104499465055023424
  15. ^1 ^2NVIDIA. "NVIDIA Launches Open Agent Safety Platform to Secure Agents From Testing to Deployment." NVIDIA Newsroom, Sept. 28, 2026. nvidianews.nvidia.com/...open-agent-safety-platform
  16. ^1 ^2 ^3 ^4 ^5 ^6Devika Verma. "Add support for Sandboxing using NVIDIA OpenShell." OpenWorker pull request #684, GitHub, merged Sept. 24, 2026. github.com/...684
  17. ^1 ^2Rohit Prasad. "Add docs for OpenShell support." OpenWorker pull request #685, GitHub, merged Sept. 24, 2026. github.com/...685
  18. ^1 ^2Devika Verma. "feat(sandbox): guided OpenShell setup, readiness checks, switching for open sessions (OPE-205, OPE-206, OPE-207, OPE-208, OPE-209)." OpenWorker pull request #699, GitHub, merged Sept. 28, 2026. github.com/...699
  19. ^1 ^2 ^3 ^4 ^5Rohit Prasad. "Sandboxing improvements for Windows and Mac." OpenWorker pull request #700, GitHub, merged Sept. 28, 2026. github.com/...700
  20. ^1 ^2Rohit Prasad. "Simplify the Sandbox settings page." OpenWorker pull request #701, GitHub, merged Sept. 29, 2026. github.com/...701
  21. ^1 ^2Rohit Prasad. "OpenShell clean-up removes only the sandboxes its own state folder made." OpenWorker pull request #704, GitHub, merged Sept. 29, 2026. github.com/...704
  22. ^1 ^2 ^3 ^4 ^5 ^6 ^7 ^8 ^9 ^10 ^11OpenWorker. "OpenShell: run an agent's commands inside a sandbox" (docs/openshell.md). GitHub, main branch, accessed Sept. 30, 2026. github.com/...openshell.md
  23. ^1 ^2 ^3 ^4 ^5 ^6OpenWorker. "The macOS sandbox: run an agent's commands behind a wall, with nothing to install" (docs/macos-sandbox.md). GitHub, main branch, accessed Sept. 30, 2026. github.com/...macos-sandbox.md
  24. ^1 ^2 ^3 ^4OpenWorker. "The Windows sandbox: run an agent's commands as an account that cannot see your files" (docs/windows-sandbox.md). GitHub, main branch, accessed Sept. 30, 2026. github.com/...windows-sandbox.md
  25. ^OpenWorker. OpenShell sandbox provider source (coworker/sandbox/providers/openshell.py). GitHub, main branch, accessed Sept. 30, 2026. github.com/...openshell.py
  26. ^NVIDIA. "Releases: NVIDIA/OpenShell" (v0.0.116, Aug. 28, 2026; v0.1.0, Sept. 25, 2026; v0.1.2, Sept. 28, 2026). GitHub, accessed Sept. 30, 2026. github.com/...releases
  27. ^1 ^2 ^3 ^4 ^5 ^6OpenWorker. "Releases: andrewyng/openworker." GitHub, accessed Sept. 30, 2026. github.com/...releases
  28. ^1 ^2 ^3 ^4 ^5OpenWorker. Desktop auto-update manifest (latest.json). Accessed Sept. 30, 2026. download.openworker.com/latest.json
  29. ^1 ^2 ^3OpenWorker. Tauri application configuration (surfaces/gui/src-tauri/tauri.conf.json). GitHub, main branch, accessed Sept. 30, 2026. github.com/...tauri.conf.json
  30. ^1 ^2 ^3 ^4Andrew Ng. "OpenWorker" repository and README. GitHub, main branch at commit ed6eb6cf145e854c6c13c067a4bec9db552aa2a1, accessed Sept. 30, 2026. github.com/...openworker
  31. ^1 ^2Andrew Ng (@AndrewYNg). Post on building an agent with the aisuite package. X, Dec. 11, 2025. x.com/...1999174188259770795
  32. ^Rohit Prasad (rohitprasad15). GitHub profile. Accessed Sept. 30, 2026. github.com/rohitprasad15
  33. ^rohit (@rohitcprasad). X profile. Accessed Sept. 30, 2026. x.com/rohitcprasad
  34. ^1 ^2OpenWorker. "Contributors to andrewyng/openworker." GitHub, accessed Sept. 30, 2026. github.com/...contributors
  35. ^jasmine889966. "Add GUI internationalization with English and Simplified Chinese." OpenWorker pull request #127, GitHub, merged Aug. 29, 2026. github.com/...127
  36. ^Devika Verma. "MCP permission model: EXTERNAL floor, durable per-tool trust, fixed approval cards (OPE-136)." OpenWorker pull request #598, GitHub, merged Sept. 3, 2026. github.com/...598
  37. ^Rohit Prasad. "Remote machines, agent-team cards, and connectors across machines." OpenWorker pull request #672, GitHub, merged Sept. 18, 2026. github.com/...672
  38. ^Rohit Prasad. "CLI: `openworker join`, `up` and `machine` commands; package publishes as `openworker`." OpenWorker pull request #673, GitHub, merged Sept. 19, 2026. github.com/...673
  39. ^Rohit Prasad. "Add Team View and harden agent-team coordination." OpenWorker pull request #679, GitHub, merged Sept. 22, 2026. github.com/...679
  40. ^Rohit Prasad. "Linux: build openworker as one program, no Python needed." OpenWorker pull request #705, GitHub, merged Sept. 29, 2026. github.com/...705

Improve this article

Add missing citations, update stale details, or suggest a clearer explanation. Every suggestion is reviewed for sourcing before it goes live.

2 revisions · v3 · 3,952 words · full history

Fact-checks are independent of edits: a reviewer re-verifies the article against its sources and stamps the date. How we verify

Research and drafting on this wiki are AI-assisted, under named human editorial standards. How AI is used here

Reviewer note: Independent verification (xg15 V5, 30 Sep 2026): I3 update checked sentence by sentence vs repo PRs, docs, releases, Ng post, NVIDIA release and partner graphic; 1 minor defect fixed in v3

Cite this page: AI Wiki. "OpenWorker." aiwiki.ai, updated 30 Sept 2026, fact-checked 30 Sept 2026. CC BY 4.0. https://aiwiki.ai/wiki/openworker

Suggest edit