cowork

Note: Cowork is currently in beta. Expect breaking changes, incomplete features, and rough edges. Feedback and contributions are welcome!

---

Why Cowork

Stop juggling ChatGPT, Claude, Gemini, and a dozen browser tabs. Cowork puts 8 AI providers, 51 skills, and 6 messaging platforms into one native desktop app that actually does things on your computer.

At a Glance

AI Providers	Google, OpenAI, Anthropic, OpenRouter, Moonshot, GLM, DeepSeek, LM Studio
Messaging	WhatsApp, Slack, Telegram, Discord, iMessage, Microsoft Teams
Skills	51 built-in skills, 10 subagents, 23 MCP connectors, 5 command packs
Platforms	macOS (Apple Silicon + Intel), Windows, Linux (deb/rpm/AppImage)
Stack	Tauri 2.0 (Rust) + React 18 + Node.js sidecar + SQLite

What You Get

• Multi-provider chat - switch AI providers mid-session, same tools everywhere
• Web search + fetch with provider-aware routing and external fallbacks (Exa / Tavily / Google)
• Media generation - images, video, editing from chat (Google / OpenAI / Fal backends)
• Browser automation - computer_use with native provider routing
• Deep research - autonomous long-form research flows
• Workflow automation - visual builder, triggers, scheduling, durable runs
• 6 messaging bridges - receive and reply across platforms from one session
• Session persistence - memory system, tool policies, permission gates

---

Platform Highlights

AI and Tooling

• Multi-provider chat with per-session provider + model
• Provider-aware web search routing with external fallbacks (Exa / Tavily / Google fallback path)
• Provider-aware web fetch routing (Anthropic web fetch, GLM web reader, Google URL-context fallback path)
• Provider-aware computer use (Google, OpenAI, Anthropic native paths; Google fallback for others when configured)
• Media backend routing independent from chat provider (Google / OpenAI / Fal)

Product UX

• Provider-first onboarding
• 3 settings tabs:
  • Provider
  • Media
  • Integrations
• Command sandbox controls in Provider settings (mode, network, path scope, trusted commands, runtime/output limits)
• Session-level Plan Mode (Plan -> <proposed_plan> -> Accept/Reject -> auto-execute on accept)
• Runtime config apply pipeline with explicit "start new session" notice when changes cross compatibility boundaries

Workflow Platform (v1)

• Workflow-first automation runtime with durable runs, node events, and replayable history
• Build workflows from chat (create_workflow_from_chat) or by using workflow management tools from main chat
• Visual workflow builder with trigger editing, step editing, publish/run actions, and run timeline inspection
• Scheduler UI shows both legacy cron entries and workflow schedules in one automation surface
• schedule_task routes new recurring automations into workflow-backed definitions
• Scheduled automations are skill-first: conversation-derived managed skills are generated and bound as mandatory execution instructions

Developer and Ops

• Tauri desktop shell with Rust command surface
• Node sidecar with JSON-RPC over stdio
• Zustand state stores with persisted settings/session metadata
• SQLite-backed persistence in sidecar storage layer

---

Provider Capability Matrix

The table below describes current runtime behavior in this repository.

Provider	Chat	Native Web Search Path	Native Web Fetch Path	Native Computer Use Path	Models API Path	Base URL Editable
Google	Yes	Yes	Yes (URL Context)	Yes	Yes	No
OpenAI	Yes	Yes	No (Google fallback path)	Yes	Yes	No
Anthropic	Yes	Yes	Yes	Yes	Yes	No
OpenRouter	Yes	No (fallback path)	No (Google fallback path)	No (Google fallback path)	Yes	Yes
Moonshot (Kimi)	Yes	Yes	No (Google fallback path)	No (Google fallback path)	Yes	Yes
GLM	Yes	Yes	Yes (web reader)	No (Google fallback path)	Curated fallback path by design	Yes
DeepSeek	Yes	No (fallback path)	No (Google fallback path)	No (Google fallback path)	Yes (curated fallback on endpoint failure)	Yes
LM Studio	Yes	No (fallback path)	No (Google fallback path)	No (Google fallback path)	Yes (curated fallback on endpoint failure)	Yes

Notes:

• Media generation is not bound to chat provider. It is controlled by media backend settings.
• Tool availability is key-gated. Missing required keys means tools are not registered.

---

Architecture

System Diagram

flowchart LR
  U["User"] --> FE["Desktop UI (React + Zustand)"]
  FE --> TAURI["Tauri Commands (Rust)"]
  TAURI --> SCM["Sidecar Manager (Rust)"]
  SCM <--> IPC["JSON-RPC over stdio"]
  IPC <--> SR["Node Sidecar Runtime"]

  SR --> AR["Agent Runner"]
  AR --> TP["Tool Policy + Permission Layer"]
  AR --> TOOLS["Tool Modules"]
  AR --> WF["Workflow Service + Engine"]
  AR --> PROV["Provider Layer"]
  AR --> STORE["Persistence (SQLite + files)"]

  TOOLS --> EXT["FS / Shell / Browser / Search / Media / MCP / Integrations"]
  PROV --> APIs["Provider APIs (Google/OpenAI/Anthropic/etc.)"]

  SR --> EVT["Event Emitter"]
  EVT --> SCM
  SCM --> FE

Message Flow

sequenceDiagram
  participant User
  participant UI as React UI
  participant Store as chat-store
  participant Rust as Tauri Rust
  participant Sidecar as Node Sidecar
  participant Agent as Agent Runner
  participant Provider as Provider API

  User->>UI: Send prompt
  UI->>Store: dispatch message
  Store->>Rust: agent_send_message
  Rust->>Sidecar: send_message (JSON-RPC)
  Sidecar->>Agent: execute turn
  Agent->>Agent: build toolset (key + capability gated)
  Agent->>Provider: stream completion / tool calls
  Provider-->>Agent: chunks + calls
  Agent-->>Sidecar: stream/tool/permission events
  Sidecar-->>Rust: event payloads
  Rust-->>UI: forwarded events
  UI->>Store: update session/chat items
  Store-->>User: render result

Runtime Config Impact Flow

sequenceDiagram
  participant Settings as Settings UI
  participant Auth as auth-store
  participant Rust as Tauri Rust
  participant Sidecar as Agent Runner
  participant Header as Session Header

  Settings->>Auth: save provider/media/integration changes
  Auth->>Rust: persist key/base URL commands
  Auth->>Rust: agent_set_runtime_config
  Rust->>Sidecar: set_runtime_config
  Sidecar-->>Rust: RuntimeConfigUpdateResult
  Rust-->>Auth: appliedImmediately/requiresNewSession/reasons
  Auth->>Header: runtimeConfigNotice state
  Header-->>User: "Start new session" notice when required

---

Tooling Model (How Tools Are Registered)

Tool registration is dynamic and session-aware:

1. Build runtime context:
   • Active provider
   • Provider/API/fallback keys
   • Media routing and specialized model IDs
2. Compute capability gates:
   • Provider-native support
   • Key presence
   • Fallback availability
3. Register only eligible tools:
   • Ineligible tools are omitted (not registered)
4. Generate system prompt tool section from registered tools

This prevents "known missing key" runtime failures by avoiding registration when configuration is incomplete.

Canonical Tool Names

• web_search (with compatibility alias google_grounded_search)
• web_fetch
• generate_image
• edit_image
• generate_video
• analyze_video
• computer_use
• deep_research
• create_workflow_from_chat
• create_workflow / update_workflow / publish_workflow
• run_workflow / manage_workflow / get_workflow_runs
• schedule_task (workflow-backed automation creation)
• draft_skill_from_conversation / create_skill_from_conversation
• plus file/system/integration tooling

---

Onboarding and Settings

Onboarding (Provider-first)

Required:

1. Name
2. Provider selection
3. Provider API key (optional for LM Studio)
4. Base URL for editable providers
5. Model selection (or custom model ID)

Optional:

• Media backend + key/model setup (Google/OpenAI/Fal)
• External search fallback config (Google/Exa/Tavily)
• Integration and capability keys (Stitch, etc.)

Settings Tabs

1. Provider
   • Active provider
   • Provider key
   • Provider base URL (editable providers only)
2. Media
   • Image/video backend routing (Google/OpenAI/Fal)
   • Google/OpenAI/Fal media keys
   • Model overrides for image/video generation
3. Integrations
   • External search fallback provider + Exa/Tavily keys

Workflow Automation

• Use chat for natural-language workflow creation and management.
• Use the Workflows view for visual graph editing, trigger configuration, and run inspection.
• Use Automations for mixed schedule visibility (legacy cron + workflow schedules).
• New recurring automation requests through schedule_task are workflow-backed.
• schedule_task now performs internal skill-first binding: it derives one or more reusable managed skills from current conversation context and injects mandatory skill-use instructions into scheduled execution prompts.

Plan Mode Workflow

Plan mode is a per-session analyze-only mode:

1. Switch the session header mode from Execute to Plan.
2. Agent investigates with read-only tool access and returns <proposed_plan>...</proposed_plan>.
3. Review the in-chat Plan Approval card:
   • Accept and Execute: switches to execute mode and auto-runs the approved plan.
   • Reject and Revise: keeps plan mode and requests a revised plan.

Plan mode tool behavior:

• Allowed: read tools, web_search, web_fetch, and safe read-only shell commands.
• Blocked: writes, destructive shell, scheduling, notifications, media generation, browser automation, and other side effects.

Execute mode discipline:

• Agent is expected to call write_todos early for multi-step work and continuously update todo statuses as execution progresses.

Runtime Apply Behavior

• Usually hot-applies:
  • key rotations
  • media backend/key/model changes
  • fallback search/integration key changes
• May require new session:
  • p