CluxMate
An AI coding agent — one Python core, three front-ends.
English · 中文文档
What is CluxMate?
CluxMate is an AI coding agent that reads your codebase, plans changes, edits files, runs commands, and answers questions. A single Python core powers three interchangeable front-ends:
| Front-end | What you get |
|---|---|
| Headless CLI | One-shot prompts for scripts, CI, and automation (cluxmate -p "...") |
| Textual TUI | A full interactive terminal UI (cluxmate) |
| Electron desktop | A polished GUI that drives the same core over JSON-RPC (stdio) |
It speaks the OpenAI-compatible API, so it works with DeepSeek, Qwen, GLM, OpenAI, OpenRouter, Ollama, or any self-hosted endpoint using the same protocol — just point it at a base_url. No vendor lock-in.
Screenshots
Highlights
- One core, three front-ends — the headless CLI, the REPL, the Textual TUI, and the Electron desktop all drive the exact same agent loop. The desktop app is a shell around that core; the Python agent remains fully usable on its own.
- No vendor lock-in — speaks any OpenAI-compatible API: DeepSeek, Qwen, GLM, OpenAI, OpenRouter, or a self-hosted endpoint. Configure multiple models and switch on the fly; provider failures never crash a turn, because timeouts, API errors, and network failures are translated into graceful, user-visible messages.
- Event-sourced sessions, fully traceable — every session is an append-only event log; the model's message history is derived from it, never stored separately. Every turn of every agent — main and subagents — is bracketed by
turn/start/turn/end, every step logsstep/start,request/header, and tool results, so the exact prompt sent at any step can be reconstructed and replayed verbatim, and context compaction rewrites a summary region without erasing the underlying events. See Sessions you can replay below. - Stable, cache-friendly context — the system prompt never changes with your session: memory, skills, and mode are injected as tagged synthetic messages, so request prefixes stay stable and prompt caches stay hot — with per-turn cache-hit and latency metrics surfaced in the UI.
- Risk-tiered permissions — every tool declares a risk level (
safe/write/dangerous/critical); four modes (plan/default/acceptEdits/yolo) plus two persistent always-allow lists (write tier + dangerous tier —delete_file, andbashper category likebash:rm/bash:python/bash:run, never whole-tool) control approval. Running code (python script.py,node app.js,npm run,./x.sh, …) isdangerous, notsafe.planmode is read-only by construction; dangerous commands prompt unless explicitly always-allowed, and critical commands (format/mkfs/dd, etc.) and sandbox escalation always prompt. - A two-layer sandbox — file write/delete tools are guarded by an in-process WriteFence (canonicalize-then-contain), and model-generated
bashcommands run inside an OS-level sandbox (Windows Low-integrity token, Linux bubblewrap, macOS Seatbelt). Sandboxing is fail-closed and onlyyolomode — the explicit opt-out — disarms it. An opt-in read denylist hides secrets (.env,*.pem,~/.ssh, …) from the model and from shell/MCP subprocesses. See Security: sandbox. - Network-access guard (SSRF) —
web_fetch/web_searchpass through an SSRF guard in every mode (includingyolo): internal/private addresses (RFC1918,
No comments yet.