OpenClerq

Roadmap

Where OpenClerq is going

0.5.1 is the current release. OpenClerq talks to eight model providers, records every run with what it cost, and can stop any of them — one run at a time, or all at once with the kill switch.

The first automation is merged and arrives in 0.6: a coding agent run on a schedule in its own git worktree, through the gates in its spec, to a draft pull request. It is not in 0.5.1, and in this first cut it runs without isolation. This page summarises the plan. The authoritative version lives in the repository and is updated there first.

Full roadmap Changelog
Released
0.5.1
Merged
0.6a · automations
Next
0.6b
Updated
2026-10-18

What changed in 0.5.1

A patch on the 0.5 line, and the first build made to update itself in place. Three of these fixes are things that quietly did less than they claimed. The 0.5 feature set is listed under that release below.

  • Skills reach the model. A skill chosen for a task now sends the instructions in its SKILL.md in the system prompt, capped at 16,000 characters. Before, only its name was sent.
  • Managed chat remembers the conversation. Earlier turns are sent with each message; every message used to be answered on its own.
  • Steadier triggers. A file trigger fires once its file has been quiet for a second, rather than once per filesystem event, and a cron or file trigger whose previous run is still going is skipped and logged instead of started again. A cron schedule naming a weekday or a day of the month could also fail to fire at all.
  • Installers attach to a tag. The publish step looked one folder too high and found none. The update manifest now names each bundle's architecture — the Apple Silicon build was listed as Intel — and a tag that does not match the app version is refused.
  • Security. The desktop app's Rust dependencies move past advisories in rustls, rustls-webpki, tar and quick-xml; proxy-addr and source-map-js are pinned to patched releases. The updater is built without its zip feature, dropping three advisories with it, so Windows releases ship the .msi and setup .exe unzipped.

Merged since 0.5.1, arriving in 0.6: scheduled automations that run a coding agent in its own git worktree and open a draft pull request. See 0.6a below.

Release trains

Shipped releases list what actually shipped. Items marked Library were built and tested ahead of the runtime that calls them; 0.6a is merged into the main branch but is not in a release yet.

  1. 0.4 — Foundation

    Shipped

    Closes the blocking security gaps. The gateway API requires authentication from this release on.

    • Loopback bind by default; a remote host needs an explicit setting 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: https only by default, every redirect checked, private and metadata ranges blocked, time and size bounds
    • CORS reflects only allow-listed origins; request bodies capped at 1 MiB
    • One version across every package and the health endpoint
    • CI gates required before build

  2. 0.5 — Execution

    Shipped

    Models, runs, and the controls around them. The execution libraries arrive ahead of the runtime that will call them. The 0.5.1 patch followed on 17 October with the fixes above.

    • Provider registry for eight vendors, overridable with your own providers.yaml
    • Token and cost accounting for every model call, recorded against its run
    • Chat console — raw and comparison modes, plus a managed mode over the existing task pipeline
    • SQLite store with migrations; memory and triggers imported once
    • Vault master key in the OS keychain, with a mode-0600 key file for headless hosts
    • Event stream, run cancellation and a kill switch
    • Approval system with risk tiers — the inbox is live; nothing raises an approval until 0.6
    • Library Sandbox profiles — native (development only, warns), macOS seatbelt, and containers as the server default
    • Library Per-run limits — wall clock and output size everywhere; CPU, memory and process count in containers
    • Library Egress allowlist enforced at the sandbox boundary through a local proxy; a profile that cannot enforce it refuses it
    • Library Policy engine — tool groups, profiles, allow and deny rules, per-run call caps
    • Library Workspaces — a git worktree per run, and a publish path that opens draft pull requests
    • Library Secrets injected into the sandbox environment only, redacted on the way back

  3. 0.6a — First automation

    Merged · unreleased

    One automation end to end: a scheduled agent that opens a gated draft pull request, and the first thing to use the policy engine and the git workspaces. It is in the main branch, not in 0.5.1.

    • Driver interface and the claude-code driver — stream parsing, cancellation, and the process group killed on cancel or timeout. It says plainly when the CLI is missing or not signed in, and runs under your own sign-in
    • YAML spec parser with line-accurate errors; documented keys this release does not run are refused by name
    • Run pipeline — worktree from origin's copy of the base branch, then the agent, the commit, the shell gates, approval, the push and a draft pull request, each state written before it starts
    • Every action decided by the policy engine; a push waits in the approvals inbox by default, and always on an automation's first push
    • Budgets per run, passed to the CLI, and per month, pausing the automation
    • One run per automation at a time, and a global cap
    • A run interrupted by a restart is marked failed and its worktree removed
    • Desktop Automations module: a spec editor that checks a spec against the machine before saving, runs with their steps and diff, and the approvals inbox

    New automations save disabled. In this first cut they run without isolation — a spec has to say sandbox: { profile: native } — and against local repositories only.

  4. 0.6b — Agents and automations

    Next

    Isolation for those runs, more drivers, and the tool-calling loop that lets a model act inside chat and tasks.

    • Seatbelt and container profiles for automation runs, with egress limited to the hosts in the spec; remote repositories
    • codex and cursor-agent drivers
    • Tool calling in the provider layer, and the builtin driver — a real tool-calling loop with every call through the policy engine
    • Agent processes left behind by a crashed gateway are killed
    • Context management — token estimation, rolling history, compaction, pinned context, tool-output truncation
    • Durable queue with leases, and catch-up for a schedule missed while the machine slept
    • Fair scheduling across repositories; retry with backoff and model escalation on gate failure
    • Gate diff.* assertions
    • Model routing and fallback chains — an explicit model choice is strict; defaults and scheduled jobs may fall back
    • 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
    • Repos and Providers screens in the rebuilt interface
    • Chat console managed mode with policy-filtered tools and inline approvals — and automations drafted by describing them, saved disabled and manual on their first run

  5. 1.0 — Platform

    Planned

    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: log in, add a repo, apply an automation, run, read 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 moves 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

  6. 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 you review in a pull request

Merged for 0.6. An automation is a file — versioned, diffable, reviewable and shareable as a recipe — that holds the schedule, the sandbox, the gates that must pass before anything ships, and the budget it may not exceed.

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

This is the full format. The first runner takes a subset of it and refuses the keys it does not yet run by name, rather than accepting them and ignoring them — so profile: container, catch_up, the routing strategy and the diff.* assertions above wait for 0.6b. The plan is 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 began as a clerical automation tool; the roadmap adds repository automation. Both run on the same engine: schedule, isolate, execute, verify, report.

Clerical work

Routine, rule-based office work for accountants, HR, legal assistants and administrators. Calculations run locally in a deterministic engine; the model advises and explains.

Repository work

Scheduled agent runs against a repository you point it at, publishing a draft pull request only when the gates in the spec pass. Merged for 0.6, on local repositories and without isolation; sandbox profiles and remote repositories follow in 0.6b.

Your agent, your subscription OpenClerq runs the agent you already use — Claude Code first, with Codex, cursor-agent and a direct model API to follow — and provides the layer around it: scheduling, isolation, model routing, verification, cost control and an audit trail. Agents run under your own subscriptions, so OpenClerq has no billing relationship with any model vendor.

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.

What is protected today, what is not yet, and the binding rules every change has to keep 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