OpenClerq

• Eight model providers. Anthropic, OpenAI, DeepSeek, Moonshot (Kimi), Z.ai (GLM), MiniMax, Ollama and LM Studio. Pick one with CLERQ_LLM_PROVIDER, or name a qualified model such as deepseek/deepseek-chat. Override the built-in registry with ~/.clerq/providers.yaml.
• Chat console. A desktop module with three modes: raw adds nothing to the conversation and shows the exact request body; managed runs the existing task pipeline; comparison sends one message to up to eight models, with latency, tokens and cost for each answer. Answers stream and can be stopped.
• Run history and cost. Tasks, trigger firings, webhooks and chat messages are recorded as runs with a step trace. Every model call records its tokens and cost against its run — and a model with no known price is reported as unknown cost, never as $0.
• Cancellation and a kill switch. Stop a single run, or refuse every pending approval, cancel every running run and pause all triggers in one call.
• Approvals and a live event stream. An approval inbox with risk tiers, where a request nobody answers is refused, and a stream of runs, model calls and approvals as they happen.
• A private local store. State moves into SQLite at ~/.clerq/clerq.db, with migrations; existing memory and triggers are imported on first start. The vault key moves into the OS keychain — macOS Keychain, libsecret or Windows DPAPI.
• Fixed: ~/.clerq and the files in it holding keys, conversations and the vault are readable only by their owner, and existing installs are repaired on startup. Persistent runs are now scheduled by the gateway, not by a timer that ran only while the developer view was open.

Built and tested, not yet wired in: the sandbox (native, macOS seatbelt and containers, with an egress allowlist), the policy engine, and git workspaces that give each run its own worktree and open draft pull requests. The approval inbox is live, but nothing raises an approval until a tool needs one in 0.6.

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.

• 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.