OpenClerq

Roadmap

Where OpenClerq is going

Release 0.4 — Security foundation — has landed. The gateway is now authenticated, bound to loopback, and covered by CI. That was the prerequisite for everything else: the moment this system gains shell execution, an open gateway is remote code execution.

Next comes execution you can leave running: sandboxing, a policy engine, approvals, and scheduled automations defined as files you can review in a pull request. This page summarises the plan. The authoritative version lives in the repository and is updated there first.

Full roadmap Changelog
Shipped
0.4.0
Next
0.5 · execution
Trains to 1.0
Three
Updated
2026-09-04

What changed in 0.4

Breaking: the gateway API now requires authentication. Every endpoint except GET /health needs a bearer token, generated on first run at ~/.clerq/gateway-token. There is no development bypass — CLERQ_DEV no longer affects access.

  • Gateway authentication. Bearer token, compared in constant time. Authentication is now separate from licensing; the entitlement check no longer stands between the network and the tool registry.
  • Loopback binding. The listener binds 127.0.0.1 unless CLERQ_HOST is set explicitly. It previously bound every interface while logging loopback.
  • Canonical path containment. File reads resolve against a real path and reject traversal, prefix-sibling escapes, absolute and UNC paths, escaping symlinks, non-regular files, and oversized reads.
  • SSRF hardening. Outbound HTTP enforces a scheme allowlist, refuses URL credentials, blocks loopback, private, CGNAT, link-local and cloud-metadata addresses, revalidates every redirect hop, and bounds redirects, time and response size.
  • CORS lockdown and a request body cap. Origins are reflected only from an allowlist; the wildcard development path is gone. JSON parsing is capped at 1 MiB.
  • CI that actually gates. Typecheck, lint, Vitest, cargo fmt/clippy/test, dependency audits and a secret scan now run before any build. The suite grew from 29 to 78 tests.
  • Fixed: single-quoted YAML frontmatter in SKILL.md is now parsed — valid YAML that had been silently producing skills the router could never select.

Four items scoped into 0.4 moved to 0.5: the SQLite store, config migration, the OS-keychain master key, and the typed event bus with its audit log.

Release trains

Sizing assumes one focused engineer. Dates are deliberately absent — the order is the commitment, not the calendar.

  1. 0.4 — Foundation

    Shipped

    Closes every blocking security finding and unifies versioning. Nothing else merged before it landed.

    • Loopback bind by default; remote host requires an explicit flag and a configured token
    • Authentication split from licensing — bearer token, public /health, everything else authenticated
    • Canonical path validation with an explicit symlink policy and size caps
    • SSRF hardening: scheme allowlist, redirect revalidation, blocked private and metadata ranges, timeouts, size caps
    • CORS locked to the desktop origin
    • Version drift fixed across every package and the health endpoint
    • CI gates required before build

  2. 0.5 — Execution

    Next · ~3 weeks

    The phase that decides whether this is safe to leave running overnight.

    • Sandbox profiles — native (development only, loudly warned), macOS seatbelt, and containers as the server default
    • Per-run limits on wall clock, CPU, memory, disk and process count, with a hard kill on breach
    • Egress allowlist enforced at the sandbox boundary rather than in application code
    • Policy engine — tool groups, profiles, allow and deny rules, per-run call caps
    • Approvals with risk tiers: allow once, allow for the session, or deny
    • Workspaces — register local paths, cache remote clones, one git worktree per run
    • Git publish path: branch, commit with a machine-identifiable trailer, push, open a pull request
    • Secrets injected as sandbox environment only, with output redaction on the way back
    • Provider registry as an editable file that updates independently of releases, plus per-call token and cost accounting
    • Durable storage — SQLite with a migration runner; JSON config files imported once and retired
    • Chat console, raw and comparison modes — talk to any model you hold a key for, or fan one message out and compare latency, tokens and cost

  3. 0.6 — Agents and automations

    Planned · ~3 weeks

    Scheduled, supervised work — and the drivers that perform it.

    • Driver interface with process supervision; each driver detects its CLI and says so plainly if absent
    • Built-in tool-calling loop, with every call routed through the policy engine
    • Context management — token estimation, rolling history, compaction, pinned context, tool-output truncation
    • Durable queue with leases and catch-up for schedules missed while the machine slept
    • Concurrency caps, fair scheduling, retry with backoff, escalation on gate failure
    • Automation spec parser and validator with line-accurate errors; gate runner for shell checks and diff assertions
    • Budget enforcement that pauses an automation rather than quietly spending
    • Memory 2.0 — typed records, full-text search, summarisation, policy-controlled retrieval
    • Sub-agents with a narrower policy than their parent, bounded in concurrency and depth
    • Desktop UI split out of one component into routed screens: Automations, Runs, Approvals, Repos, Providers
    • Chat console, managed mode — and drafting automations by describing them, saved disabled and manual on first run

  4. 1.0 — Platform

    Planned · ~3 weeks plus hardening

    Headless installs, real signing, and a plugin contract proven by using it.

    • GitHub sign-in through a GitHub App — short-lived installation tokens, per-repo scope, revocable
    • Headless daemon with a systemd unit, a Docker image and reverse-proxy guidance
    • Command-line client: login, add a repo, apply an automation, run, tail logs, approve
    • Linux packages in the release matrix, a one-line installer and a one-line container run
    • Restrictive content security policy in the desktop shell; real updater signing keys with documented rotation
    • Plugin SDK with declared permissions and a lifecycle — the chat console migrates onto it as the reference first-party plugin
    • Skill manifests declaring required tools, network domains and filesystem scope, with checksums and trust states
    • Versioned API protocol, migrations, and a published threat model

  5. After 1.0

    Exploring

    Routing strategies — cost-aware, quality-first, race, consensus · fleet runs across many repositories with roll-up reporting · a recipe registry · run replay and cost analytics · exposure as an MCP server so other agents can drive OpenClerq · a browser module · an optional channel adapter.

Automations are files, not database rows

An automation is a spec you can version, diff, review in a pull request and share as a recipe — with the schedule, the sandbox, the gates that must pass before anything ships, and the budget it may not exceed, all in one place.

name: nightly-dependency-triage

on:
  schedule: '0 3 * * 1-5'     # weekday 03:00, host timezone
  catch_up: true              # run once on wake if the slot was missed

agent:
  driver: claude-code         # or codex, cursor-agent, builtin
  model:
    primary: claude-opus-5
    strategy: cost_aware

sandbox:
  profile: container
  network: [registry.npmjs.org, api.github.com]
  timeout: 20m

gates:                        # all must pass or the run does not publish
  - run: pnpm test
  - assert: diff.files_changed <= 5

publish:
  pull_request: draft

budget:
  max_usd_per_run: 2.00
  on_exceed: pause_automation

Three surfaces over the same object: a form, a YAML pane, and a command-line apply for people who want their automations managed by CI.

Two domains, one engine

OpenClerq's origin is clerical automation, and that remains the product. The roadmap adds repository automation on top of the same engine — schedule, isolate, execute, verify, report — because document processing and dependency triage are the same shape of problem.

Clerical work

Routine, rule-based office work for accountants, HR, legal assistants and administrators. Calculations run locally; AI advises and explains. This is the larger market and the reason the project exists.

Repository work

Scheduled, sandboxed agent runs against repositories you point it at, publishing gated draft pull requests. A proven market that exercises the same scheduling, isolation and verification layer.

The position: OpenClerq is the conductor, not another agent. It supervises whichever agent runtime you already pay for, on hardware you control. Because those runtimes run under your own subscriptions, OpenClerq takes no margin on inference — which is the structural reason it can stay free and open source.

What we deliberately do not build

Restraint is a feature. A smaller core with stronger boundaries is the position.

  • Localhost is not authentication. A loopback bind is never treated as an authorisation decision.
  • Developer mode is not production authority. No debug flag may disable authentication.
  • Skills do not imply permissions. A skill declares what it needs; the policy engine decides.
  • Push is not merge. Draft pull requests by default; auto-merge is opt-in and gated.
  • No self-arming automations. A spec drafted in conversation saves disabled and pushes manually on its first run, whatever the draft asked for.
  • Raw chat gets no tools. There is no mode that strips the prompt scaffolding while keeping filesystem or shell reach.
  • No autonomous loop without a budget and a timeout, and no sub-agent with a wider policy than its parent.
  • No unrestricted plugins. Executable plugins are code, and declare their permissions.

Be clear-eyed about what this is: a system that takes natural language, hands it to a model, and executes the result with filesystem, shell, network and git access. Handled carelessly that is remote code execution with a friendly interface. The full threat model and the binding rules are in SECURITY.md.

Follow along or shape it

The roadmap changes as the work does. Issues and pull requests are the place to argue with it — and if you need a specific desktop worker built on this core, tell us what it has to do.

OpenClerq on GitHub Clerq for Business