Sigma

Sigma Code

The open-source coding agent that survives interruptions and proves its changes. Run long coding tasks in a native sandbox, resume anytime, and finish with evidence.

English · 简体中文

Download v0.1.4 · Desktop client source · Security

The Sigma Code desktop client is an independently maintained downstream of T3 Code and connects to this runtime over ACP v1.

Sigma Code is built for coding tasks that must not lose their state or declare victory too early. It runs commands inside a required native sandbox, persists the full working session so it can resume after interruption, and completes only after current changes are validated and any required review is satisfied. This repository owns Sigma Runtime, the CLI, and the TUI; the desktop, Web, and mobile client lives in hututuQQQ/sigma-code. Every surface uses the same event-sourced kernel, session store, tools, recovery logic, and outcome protocol, either in process through RuntimeClient or over stable ACP v1.

0.1.4 is the current supported product baseline. Linux x64 is the stable release target. Windows x64 remains an explicitly unsigned preview until trusted Authenticode signing is available. See the [security policy](SECURITY.md) and [contribution guide](CONTRIBUTING.md) before reporting or proposing changes.

> [!TIP] > OpenCode comparison—same model, all 89 tasks: Sigma Code + DeepSeek completed 51/89 (57.303%) while OpenCode + DeepSeek completed 49/89 (55.056%), a difference of +2 passes / +2.247 percentage points. Both agents ran DeepSeek deepseek-v4-pro on the same Terminal-Bench 2.1 population; Sigma used one attempt per task, zero retries, and no verifier feedback. Methodology and limitations are documented under [Evaluation and benchmark boundary](#evaluation-and-benchmark-boundary).

> [!IMPORTANT] > Current product boundary > > - Sigma Code 0.1.4 is stable on Linux x64; Windows x64 is an unsigned preview. The Windows installer contains both the Sigma Code desktop UI and the verified Sigma Runtime, so users do not need a separate Node.js or agent CLI installation. Release candidates must pass native sandbox, packaged-product, checksum, SBOM, and signed-provenance gates. Windows executables do not yet have a trusted Authenticode signature and may trigger Windows security warnings. > - Formal evaluation is preregistered, not provider-coded. The SHA-bound run manifest freezes the provider, model, source, archive, task selection, network, timeouts, concurrency, attempts, and retries before execution. > - Provider comparisons are valid only when their SHA-bound run manifests freeze comparable controls; the harness does not infer comparability from a model name.

Why Sigma Code

| Core capability | What it means for you | | --- | --- | | Native sandbox execution | Commands stay inside required OS-level isolation. If the sandbox is unhealthy, Sigma refuses to execute. | | Sessions that survive interruption | Commands, model turns, tool receipts, plans, and outcomes are persisted as checksummed events, so the same task can be resumed and replayed. | | Evidence before completion | Model prose alone cannot mark changed work as done. Sigma requires current-state validation and any required review evidence. |

Sigma Code desktop and T3 integration

The Sigma Code client is an independently maintained desktop, Web, and mobile downstream of T3 Code. The original T3 Code license and attribution are preserved in that repository; the downstream is not affiliated with or endorsed by T3 Tools, Inc.

The Windows installer published from this repository bundles the client with the exact verified Sigma Runtime from the same release. Its first-party Sigma provider starts the long-lived sigma acp server and communicates through newline-delimited JSON-RPC over stdio. The v0.1.4 bridge supports:

• creating, listing, loading, resuming, closing, cancelling, and steering durable sessions;
• streamed model and reasoning text, plans, tool calls, approvals, usage, context-window status, hooks, and child-agent lifecycle events;
• image prompts, structured user questions, authoritative persisted history, and append-only message rollback;
• model and model-specific reasoning-level selection, trusted skill discovery, and client-supplied Streamable HTTP MCP servers.

For the first-party Sigma provider, the client remains a presentation surface: execution, permissions, sandboxing, persistence, validation, review, and recovery stay authoritative in Sigma Runtime.

Terminal UI

Quick start on Linux

Obtain the 0.1.4 Linux x64 stable archive from a verified project release or build it from source, verify its SHA-256 sidecar and signed provenance, and extract it:

SIGMA="$HOME/.local/share/sigma-code"
WORKSPACE="/path/to/your/repository"

export DEEPSEEK_API_KEY="your-api-key"

"$SIGMA/bin/agent" init --workspace "$WORKSPACE" --provider deepseek
"$SIGMA/bin/agent" doctor --workspace "$WORKSPACE" --check-api
"$SIGMA/bin/agent" tui --workspace "$WORKSPACE"

Quick start on Windows (unsigned preview)

> [!WARNING] > The Windows x64 archive is an unsigned preview, not an official trusted Windows > binary release. Verify its SHA-256 sidecar and signed provenance before extraction. > Its executables do not have a trusted Authenticode signature, so Windows SmartScreen > or Smart App Control may warn or block execution.

For the complete desktop product, download Sigma-Code-0.1.4-x64.exe from the Sigma Code v0.1.4 release, verify its SHA-256 sidecar, and run the installer. It installs the Sigma Code UI together with the verified Sigma Runtime; no separate Node.js or agent CLI installation is required.

The bundled UI is built from hututuQQQ/sigma-code and launches the Runtime through sigma acp. In Settings, choose a Sigma model connection and authenticate with the method exposed by that provider. The default desktop path uses the experimental ChatGPT/Codex subscription connection; supported Pi providers can expose API-key or OAuth methods through the same Runtime-owned interface.

The agent-cli-win32-x64.zip asset remains available for terminal-only and portable use. It includes pinned Node.js, the native sigma-exec broker, the TUI runtime, TypeScript/Python language-server assets, and tokenizer data.

$Sigma = "C:\Tools\sigma-code"
$Workspace = "D:\path\to\your\repository"

$env:DEEPSEEK_API_KEY = "your-api-key"

# One-time setup for the current Windows user.
& "$Sigma\bin\agent.cmd" sandbox setup

# Create workspace configuration, verify the runtime and provider, then enter the TUI.
& "$Sigma\bin\agent.cmd" init --workspace $Workspace --provider deepseek
& "$Sigma\bin\agent.cmd" doctor --workspace $Workspace --check-api
& "$Sigma\bin\agent.cmd" tui --workspace $Workspace

The example sets the key only for the current PowerShell process. Keep secrets out of .agent/config.toml and source control.

Published archives include a SHA-256 checksum, CycloneDX SBOM, signed provenance, and the public provenance verification key. Linux x64 is stable at 0.1.4; Windows x64 remains an unsigned preview. See [SECURITY.md](SECURITY.md) for the trust boundary and [RELEASING.md](RELEASING.md) for the maintainer process.

For a one-shot task:

& "$Sigma\bin\agent.cmd" run "Fix the failing tests and explain the change" `
  --workspace $Workspace `
  --permission-mode auto

For read-only analysis:

& "$Sigma\bin\agent.cmd" inspect "Map the request path and identify reliability risks" `
  --workspace $Workspace `
  --permission-mode auto

run uses change mode. inspect uses analyze mode and rejects tools whose declared effects include filesystem writes, unrestricted process spawning, or destructive work.

What Sigma can do

• Desktop and terminal interaction: use the Sigma Code desktop client through ACP v1, or a CJK/IME-aware terminal UI with Markdown responses, activity views, command completion, multiline input, steering, follow-ups, scrolling, and approval overlays.
• Unified model access: search the pinned Pi catalog, authenticate provider connections, select model-specific reasoning levels, and retain explicit metered, subscription, or unknown-price billing semantics.
• Repository intelligence: bounded file listing and grep, repository statistics, Git status/diff, stable hash-aware workspace and declared host-input reads, nested AGENTS.md discovery, and LSP-backed code intelligence when a supported server is available.
• Scoped changes: write and edit files, apply atomic multi-file patches, delete individual files, detect no-op writes, create mutation checkpoints, and restore the current run's latest sealed checkpoint.
• Sandboxed execution: run direct executables or platform shells, execute semantic validation, manage background/PTY processes through broker-scoped session handles, and explicitly hand off verified Linux deliverable services.
• Read-only Web research: use web_run (web.run in documentation) to search, open, find, and follow numbered static links. Results retain durable references and are always marked as untrusted external content.
• Evidence-based delivery: record workspace deltas, commands, validation, diagnostics, reviews, child outcomes, and checkpoints in one typed evidence ledger.
• Durable sessions: list, inspect, replay, resume, cancel, steer, approve, and continue sessions after a process interruption.
• Child agents: delegate plan nodes to bounded child sessions; isolate writers in Git worktrees or narrow single-writer scopes, then explicitly integrate retained changes.
• Long-running reliability: compact context before the provider window is exhausted, recover boundedly from transient stream closures, and isolate reviewer sessions and child runs from later turns.
• Extensibility: load skills, profiles, and hooks through frozen/trusted customization boundaries, connect explicitly trusted read-only MCP stdio servers, and accept read-only Streamable HTTP MCP servers supplied by an ACP client.

Architecture

agent-runtime.createConfiguredRuntime is the single production composition root. It wires the model routes, context provider, pure kernel, effect-aware tools, MCP clients, segmented event store, checkpoint manager, reviewer, supervisor, execution broker, and in-process RuntimeClient. The CLI creates that runtime; the TUI receives the client rather than rebuilding the agent loop, and sigma acp projects the same runtime to clients such as Sigma Code.

flowchart TB
  USER["Terminal user"] --> CLI["agent-clicommands + TUI"]
  DESKTOP["Sigma Code desktopT3 Code downstream"]  ACP["sigma acpstable ACP v1"]
  CLI --> ROOT["agent-runtimesingle composition root"]
  ACP --> ROOT
  ROOT --> CLIENT["RuntimeClientsession command bus"]
  CLIENT --> KERNEL["agent-kernelpure reducer + effect decisions"]

  KERNEL --> MODEL["agent-modelrouting, budgets, retry policy"]
  MODEL --> PI["agent-pi + pi-aiprovider auth and model transport"]
  KERNEL --> CONTEXT["agent-contextinstructions, retrieval, token budget"]
  KERNEL --> TOOLS["agent-toolstyped effect plans and receipts"]
  KERNEL --> STORE["agent-storeevents, snapshots, artifacts"]

  TOOLS --> MCP["agent-mcptrusted stdio + ACP HTTP bridge"]
  TOOLS --> SUP["agent-supervisorchildren, mailboxes, writer isolation"]
  TOOLS --> EXEC["agent-executiononly arbitrary-process boundary"]
  EXEC --> NATIVE["sigma-exec (Rust)Windows AppContainer / Linux namespace sandbox"]

  MODEL --> EVENTS["AgentEventEnvelope"]
  CONTEXT --> EVENTS
  TOOLS --> EVENTS
  SUP --> EVENTS
  EVENTS --> STORE
  EVENTS --> KERNEL
  EVENTS --> PRESENT["agent-presentationincremental projection"]
  PRESENT --> TUI["agent-tuiOpenTUI renderer"]
  EVENTS --> ACP

  EVAL["External evaluation + benchmark harness"] -.->|"launch packaged subject; collect only after run"| CLI

The event loop

1. A CLI, TUI, or ACP command becomes a typed session command and durable event.
2. agent-kernel reduces the event stream into state and decides the next effect; it does not perform I/O itself.
3. agent-runtime executes that decision through protocol ports for the model, context, tools, store, review, or supervision.
4. Before a tool runs, Sigma freezes its exact read/write roots, network mode, process mode, idempotence, and checkpoint scope. Mode policy, approval, locks, and trust checks are evaluated against that plan.
5. The resulting receipt and evidence are appended as new events. The kernel then decides the next step from durable state, while agent-presentation and the ACP bridge project the same events into terminal or desktop updates.
6. A run ends only with a typed outcome: Completed, NeedsInput, Cancelled, RecoverableFailure, or Fatal.

This separation makes replay and recovery part of the normal execution model instead of a special UI feature.

Package map

| Layer | Packages | Responsibility | | --- | --- | --- | | Contracts | agent-protocol, agent-config | Events, commands, outcomes, ports, tool effects, model capabilities, and the shared CLI/env/TOML schema. | | Decision engine | agent-kernel | Pure state reduction, convergence rules, terminal protocol repair, and effect selection. | | Intelligence | agent-model, agent-pi, agent-context, agent-code-intel, agent-extensions | Model policy, unified Pi provider transport, context fitting/compaction, repository instructions, LSP, skills, profiles, and hooks. | | Capabilities | agent-tools, agent-web, agent-mcp | Repository/file/process/control/supervisor tools, brokered Web research, and the MCP bridge, all behind declared effects. | | Safety boundary | agent-execution, agent-platform, agent-checkpoint, native/sigma-exec | Path containment, process policy, native sandboxing, output redaction/artifacts, and transactional recovery. | | Durability and coordination | agent-store, agent-supervisor, agent-runtime | Event persistence, snapshots, session ownership, child isolation, recovery, review, and composition. | | Product surfaces | agent-presentation, agent-tui, agent-cli; downstream sigma-code | Event projection, terminal interaction, automation commands, ACP v1, desktop interaction, session administration, and diagnostics. |

The production package dependency graph is checked for cycles and packages communicate through public exports.

Safety, permissions, and recovery

Execution boundary

agent-execution is the only production package allowed to start arbitrary processes. It talks to the bundled Rust sigma-exec broker over a framed protocol. On Windows, each sandboxed command uses an AppContainer identity with scoped filesystem ACLs, a kill-on-close Job Object, capability-gated networking, and ConPTY for interactive processes. Linux uses the native namespace sandbox and a watchdog for process-tree cleanup.

Configuration schema 1 defaults to permission_mode=workspace-auto, sandbox=required, read_scope=workspace, network=full, web.mode=auto, process_handoff=allow, and the native sandbox backend. Workspace-scoped reads and declared writes run automatically; external reads, full-network calls, and repository metadata writes remain separately authorized. An explicit network=none or network=loopback setting narrows the capability. Required isolation never falls back to host execution, and container mode fails with container_unavailable until a real OCI backend is installed.

web_run is exposed only when full network access is enabled, Web mode is not

…

Source & license

This open-source MCP server is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: hututuQQQ
• Source: hututuQQQ/sigma
• License: MIT
• Homepage: https://sigma-code-agent.a962950733.chatgpt.site/

Install and usage instructions live in the source repository linked above.