openworker - Moses Yebei

The Problem

OpenWorker addresses the gap between conversational AI assistants and actual task completion. Most AI tools produce chat responses or to-do lists, leaving the user to do the real work: drafting the document, sending the Slack message, updating the calendar. OpenWorker positions itself as an "AI coworker" that runs on the desktop, executes multi-step tasks across files and connected applications, and delivers finished artifacts rather than instructions.

What This Does

The repo implements a desktop application with a local Python agent server (coworker/server/app.py) and a native GUI shell (surfaces/gui/). The core engine (coworker/engine.py) orchestrates agents that break tasks into steps and execute them via a connector system. The coworker/connectors/ directory contains 25+ integrations—GitHub, Slack, Gmail, Google Calendar, HubSpot—plus MCP support for external tools.

The system is approval-gated: consequential actions like sending messages or running shell commands require user confirmation. The coworker/automation/ module handles scheduled recurring tasks. Model access is bring-your-own-key, supporting OpenAI, Anthropic, Google, and local models via Ollama.

How It Is Wired

Execution starts at coworker/cli.py or the GUI's server entry point. The server receives a task, coworker/engine.py decomposes it, and coworker/agents/registry.py selects the appropriate agent. Agents call tools through coworker/connectors/tools.py, which routes to specific connectors like gmail_accounts.py or slack_addr.py. The coworker/connectors/gateway.py handles external API calls.

Key routing functions: coworker/engine.py orchestrates task flow; coworker/connectors/tools.py dispatches to integrations. The approval system lives in coworker/approval.py and gates write operations. The coworker/automation/scheduler.py handles scheduled runs.

The wiring has not been fully mapped for this repository—the module graph and call paths are incomplete. What is clear: the Python backend is the control plane, the Rust component (stt/) handles speech-to-text, and the TypeScript/React GUI (surfaces/gui/src-tauri/) is a Tauri shell.

How To Use It

Setup: The README points to prebuilt installers for macOS (Apple Silicon) and Windows. For source builds, pyproject.toml implies pip/uv for Python, surfaces/gui/package.json implies npm for the GUI, and stt/Cargo.toml implies cargo for the Rust component.

Configuration: Model API keys are required. The README says to add a key in the app or point it at Ollama. The exact config file is coworker/config.py.

Running it: The README documents no CLI commands—the intended path is the desktop app. For development, coworker/cli.py is the Python entry point.

# Python backend (from repo root)
pip install -e .
python -m coworker.cli

# GUI (from surfaces/gui)
npm install
npm run dev

Real-World Use

A typical scenario: a user asks the agent to "prepare a customer brief for tomorrow's meeting." The engine breaks this into steps—gather data from HubSpot, pull recent emails from Gmail, draft the document, save it to the filesystem. Each step routes through coworker/connectors/tools.py to the relevant connector, and the final document lands as a file. The user approves the send if the task includes emailing it.

Code Health & Issues

Static analysis found one issue:

Low/Security - Secret-shaped paths present in coworker/secrets.py and tests/test_secrets.py. Verify these are not committing credentials.

SDLC observations from the structure:

Med - 242 test files exist but the repo has no documented test runner command in the README.
Low - No Dockerfile or containerization, limiting deployment options for the server component.
Low - The repo is a fork of andrewyng/openworker with 0 stars; active upstream development may make this fork stale.

The Bottom Line

OpenWorker is a serious attempt at a desktop AI agent with real tool integration and approval gating. The architecture is sound—Python backend, connector abstraction, Tauri GUI—but the wiring is not fully documented and the fork has no community traction. Use it if you want a local, model-agnostic agent with Slack integration and scheduled tasks, but expect to read source to understand the full flow.

What the analyser found

Deployment readiness

5/7

Container image
CI pipeline
Lockfile committed
Test suite
README
License
No committed secrets

Composition

612 files

Python282
TypeScript106
TSX85
Markdown39
JSON7
HTML5

ReactDjangoFlaskTailwind

Architecture

Top-level areas of the codebase, sized by module count. Arrows show how many imports cross from one area into another.

graph TD g0["surfaces 193 modules"] g1["coworker 148 modules"] g2["tests 128 modules"] g3["scripts 4 modules"] g4["packaging 2 modules"] g2 -->|580| g1 g3 -->|5| g1 g2 -->|2| g3 g4 -->|1| g1

Module dependencies

The 10 most depended-upon modules of 475, from static import analysis. Red outline marks a module in an import cycle.

graph LR n0_surfaces_gui_e2e_fixtures["fixtures"] n1_coworker_providers___init__["__init__"] n2_coworker_secrets["secrets"] n3_surfaces_gui_src_api["api"] n4_coworker_server_manager["manager"] n5_aces_gui_src_components_Icon["Icon"] n6_coworker_permissions["permissions"] n7_coworker_connectors_base["base"] n8_coworker_connectors___init__["__init__"] n9_surfaces_gui_src_types["types"] n8_coworker_connectors___init__ --> n7_coworker_connectors_base n6_coworker_permissions --> n2_coworker_secrets n4_coworker_server_manager --> n8_coworker_connectors___init__ n4_coworker_server_manager --> n6_coworker_permissions n4_coworker_server_manager --> n1_coworker_providers___init__ n4_coworker_server_manager --> n2_coworker_secrets n4_coworker_server_manager --> n7_coworker_connectors_base n3_surfaces_gui_src_api --> n9_surfaces_gui_src_types n9_surfaces_gui_src_types --> n3_surfaces_gui_src_api classDef cyc stroke:#ef4444,stroke-width:2px; class n3_surfaces_gui_src_api,n8_coworker_connectors___init__,n9_surfaces_gui_src_types cyc;

Dependencies

19 of 61 declared dependencies are a major version behind. Resolved 51 of 61 against the registry.

Package	Declared	Latest	Behind
`textual`	>=1.0	8.2.8	7 major
`jsdom`	^25.0.1	30.0.1	5 major
`websockets`	>=13	17.0.1	4 major
`croniter`	>=2	6.2.4	4 major
`vite`	^5.4.0	8.2.1	3 major
`openai`	>=1.0	3.1.0	2 major
`pdfjs-dist`	^4.10.38	6.2.108	2 major
`@vitejs/plugin-react`	^4.3.1	6.0.5	2 major

Findings

LowSecret-shaped paths present; the code-health audit confirms or clears them coworker/secrets.py, tests/test_secrets.py

What would stop me shipping this

Ranked by severity × confidence × production reach. Reach is the honest discriminator across a collection that is mostly other people's code: the same finding matters more in something that ships.

high2

medium4

low2

Pin third-party GitHub Actions to a commit SHAhigh3 occurrences

.github/workflows

dtolnay/rust-toolchain@stable, Swatinem/rust-cache@v2, softprops/action-gh-release@v2

A tag can be moved, so the action running with your token and secrets is whatever its owner last pushed; this is how tj-actions/changed-files leaked secrets from thousands of repos.

Fix: Replace each @vN with the 40-character commit SHA, keep # vN as a comment, and let Dependabot bump the SHAs.

Commit a lockfile beside the manifesthigh

pyproject.toml

manifest with no lockfile in scope

An unlocked range means the artifact you tested and the artifact you ship can contain different transitive code, so a malicious patch release reaches production with no diff.

Fix: Run the package manager once and commit the generated lockfile.

Declare least-privilege permissions for GITHUB_TOKENmedium

.github/workflows/ci.yml

1 workflow(s) declare no permissions

With no declaration the token inherits the repository default, so any injected step can push commits or mint releases from inside your own CI.

Fix: Add permissions: contents: read at the top of the workflow and widen per job only where needed.

Enable Dependabot or Renovatemedium

4 manifest(s), no update bot configured

Without a bot a published advisory sits unpatched until someone audits by hand, which across 1,322 repositories means never.

Fix: Commit .github/dependabot.yml covering the repo ecosystems plus github-actions.

Gate pull requests on a dependency vulnerability scanmedium

.github/workflows

no dependency scan in CI

This is the one gate that would catch a known-vulnerable package before it reaches a build, and no repository in the sample had it.

Fix: Add dependency-review-action on pull_request, or osv-scanner on push and a schedule.

Set persist-credentials: false on checkoutmedium

.github/workflows/ci.yml

checkout keeps the token, then dependencies are installed

The token stays in .git/config for every later step, so a malicious postinstall script reads a pushable credential without one ever being passed to it.

Fix: Add with: persist-credentials: false, and pass an explicit token only to the step that pushes.

Set timeout-minutes on the workflow jobslow2 occurrences

.github/workflows/ci.yml

2 workflow(s) declare no job timeout

A wedged step runs to the six-hour platform default, which on a two-hourly schedule means three runs overlap behind it.

Fix: Add timeout-minutes with a realistic bound to each job.

Add the repository convention files this project lackslow3 occurrences

missing .editorconfig, .gitattributes, a formatter config

Without them one contributor's editor writes tabs into a Python file, a shell script commits with CRLF and fails in the container, and a notebook diff is unreviewable.

Fix: Add .editorconfig, .gitattributes with text=auto eol=lf, and a formatter config.

Checked deterministically against the repository tree and a bounded set of its files: committed credentials, unpinned actions and base images, missing lockfiles and update bots, workflows that discard failures, published advisories against the declared dependencies, runtime configuration, licensing and notebook reproducibility. No language model is involved in this section.