anion-public
Public architecture and product documentation for Anion — a local AI operating layer for the Linux desktop.
Links
README
From the repo.
🧠 Anion
A local AI operating layer for the Linux desktop.
Linux-native · Local-first · ARIA-powered · Terminal-aware · Privacy-conscious
Architecture · Features · ARIA · Testing · Roadmap · Beta Access
Public documentation repository This repository documents Anion’s architecture, product design, features, screenshots, diagrams, release notes, and beta access. The production source code is private during beta and security hardening.
🎯 Recruiter Snapshot
| Signal | What it shows |
|---|---|
| End-to-end system | Built a Linux-native AI desktop layer combining Python backend services, Electron/React UI, Ollama local models, ARIA agent runtime, terminal intelligence, and context/memory systems. |
| AI infrastructure | Designed local model runtime integration, local services, context pipelines, and backend-driven UI state. |
| Agentic safety | Built a bounded assistant with tool allowlists, risk tiers, privacy checks, and approval-required actions. |
| Release discipline | Implemented release-focused testing across quick, full, e2e, chaos, soak, security, and gate validation flows. |
| Relevant roles | AI infrastructure, ML systems design, local AI runtimes, agentic systems, developer tooling, Linux services. |
⚡ Overview
Anion is a privacy-first AI assistant layer built for the Linux desktop.
It connects local model inference, terminal intelligence, desktop context, workspace awareness, memory, and a real-time desktop shell into one local-first AI system.
Most AI assistants live in a browser tab. Anion is designed to live beside the operating system.
It can understand the current desktop workflow, reason over local context, assist through ARIA, and surface useful automation while keeping sensitive actions bounded by guardrails and approval flows.
🖼️ Product Preview
Anion control plane showing local AI state, system context, and runtime status.
🧩 What I Built
🧠 AI Runtime Layer
|
🖥️ Linux Desktop Layer
|
🧪 Reliability Layer
|
🔐 Privacy + Safety Layer
|
🏗️ Architecture Overview
flowchart TD
A[Linux Desktop] --> B[systemd User Services]
B --> C[Anion Python Backend]
C --> D[Context Engine]
C --> E[Memory Layer<br/>SQLite / WAL]
C --> F[ARIA Agent<br/>Bounded ReAct Loop]
C --> G[Terminal Intelligence]
C --> K[Ollama<br/>Local LLM Runtime]
F --> H[Tool Allowlist<br/>Guardrails<br/>Risk Tiers]
C --> I[Local HTTP / SSE Bridge<br/>127.0.0.1:9120]
I --> J[Electron / React Shell]
C --> L[Cross-Device Sync]
L --> M[Pairing + Encrypted Channel]
style A fill:#020617,stroke:#00D1FF,color:#fff
style C fill:#111827,stroke:#8B5CF6,color:#fff
style F fill:#111827,stroke:#F59E0B,color:#fff
style I fill:#111827,stroke:#06B6D4,color:#fff
style J fill:#111827,stroke:#10B981,color:#fff
style K fill:#111827,stroke:#EC4899,color:#fff
Design principle
The backend is active. The frontend is a live renderer.
The Electron shell does not own the core intelligence. It reflects backend state streamed through the local HTTP/SSE bridge. This keeps orchestration, memory, tool execution, and guardrails in the Python backend instead of scattering logic across the UI.
🗺️ Architecture Map
This repository includes standalone Mermaid diagrams for recruiter-friendly technical review.
| Diagram | What it explains |
|---|---|
architecture-overview.mmd | Full system architecture and service boundaries |
aria-agent-flow.mmd | ARIA request → reasoning → guardrail → tool flow |
context-memory-flow.mmd | Desktop, terminal, file, and memory data flow |
cross-device-sync-flow.mmd | LAN discovery, pairing, encryption, and resume flow |
terminal-intelligence-flow.mmd | Command execution, risk preview, and recovery |
testing-pipeline.mmd | Test harness, security scans, and release gate |
privacy-boundary.mmd | Local-first privacy boundary and external-service controls |
See assets/diagrams/README.md for rendering notes.
🤖 ARIA Agent Flow
ARIA is Anion’s bounded agentic assistant. It can reason through tasks and use approved tools, but it does not get unrestricted shell access.
sequenceDiagram
participant U as User
participant UI as Anion Shell
participant A as ARIA Agent
participant P as Privacy Redactor
participant G as Guardrails
participant O as Ollama
participant T as Approved Tool
U->>UI: Ask request
UI->>A: Prompt + context
A->>P: Check sensitive content
P-->>A: Safe / redacted / local-only
A->>O: Reason over task
O-->>A: Plan or tool proposal
A->>G: Validate tool + risk tier
alt Safe tool
G-->>A: Allowed
A->>T: Execute approved tool
T-->>A: Tool result
A-->>UI: Final response
else Sensitive action
G-->>A: Approval required
A-->>UI: Ask user for approval
end
Read more: docs/ARIA_AGENT.md
🧠 Context + Memory Flow
Anion is context-aware because it listens to real Linux workflow signals.
flowchart TD
A[Active Window / Workspace] --> D[Context Engine]
B[Terminal Activity] --> D
C[File Events / Pinned Files] --> D
D --> E[Local Memory Store]
E --> F[Semantic Context Retrieval]
F --> G[ARIA Assistant]
D --> H[Anion Shell]
E --> H
style D fill:#111827,stroke:#06B6D4,color:#fff
style E fill:#111827,stroke:#8B5CF6,color:#fff
style G fill:#111827,stroke:#F59E0B,color:#fff
Read more: docs/CONTEXT_AND_MEMORY.md
🖥️ Terminal Intelligence Flow
Anion’s terminal layer is designed for developer workflows: history, recovery, and risk previews.
flowchart TD
A[User enters command] --> B[Terminal Wrapper]
B --> C{Risk preview}
C -->|Safe| D[Execute command]
C -->|Risky| E[Require confirmation]
E -->|Approved| D
E -->|Rejected| F[Cancel execution]
D --> G{Command failed?}
G -->|No| H[Store history]
G -->|Yes| I[Recovery Engine]
I --> J[Rule-based fix or LLM suggestion]
J --> H
style C fill:#111827,stroke:#F59E0B,color:#fff
style E fill:#111827,stroke:#EF4444,color:#fff
style I fill:#111827,stroke:#06B6D4,color:#fff
Read more: docs/TERMINAL_INTELLIGENCE.md
🔄 Cross-Device Sync Flow
Anion supports local-network context handoff between Linux machines.
flowchart LR
A[Linux Device A] --> B[LAN Discovery]
C[Linux Device B] --> B
B --> D[Pairing Flow]
D --> E[PIN Verification]
E --> F[Encrypted Channel]
F --> G[Context Sync]
G --> H[Resume Work]
style B fill:#111827,stroke:#06B6D4,color:#fff
style E fill:#111827,stroke:#F59E0B,color:#fff
style F fill:#111827,stroke:#10B981,color:#fff
Read more: docs/CROSS_DEVICE_SYNC.md
✨ Key Features
🤖 ARIA AssistantA bounded agentic assistant with tool schemas, risk tiers, privacy checks, and approval-required actions. Highlights
|
🖥️ Terminal IntelligenceA safer terminal workflow with persistent history, deterministic risk preview, and common-error recovery. Highlights
|
🧠 Context + MemoryA local context layer that collects workflow signals and makes them useful to ARIA. Highlights
|
🔐 Privacy + GuardrailsAnion is designed around local-first execution and explicit control over sensitive actions. Highlights
|
🔄 Cross-Device SyncA private-beta sync flow for continuing context across Linux machines. Highlights
|
🧬 Live Desktop ShellElectron/React shell that visualizes Anion state through a real-time backend stream. Highlights
|
🖥️ Interface Gallery
ARIA Assistant Bounded agentic assistant for local Linux workflows. |
Live System Brain Visual runtime layer for context, memory, and local AI state. |
Model Hub Local model management and Ollama-ready workflows. |
Smart Hub Workflow intelligence, suggestions, and system-level assistance. |
Control View System controls, diagnostics, and runtime visibility. |
Explore Context exploration across workspace, memory, and local activity. |
🧑💻 Terminal Screenshots
Terminal Screenshot 1 |
Terminal Screenshot 2 |
Terminal Screenshot 3 |
Terminal Screenshot 4 |
Terminal Screenshot 5 |
Terminal Screenshot 6 |
🛠️ Tech Stack
| Layer | Technology |
|---|---|
| Backend | Python 3.11+, local daemons, SQLite/WAL |
| Frontend | Electron, React, Vite, Three.js |
| AI Runtime | Ollama local models |
| Agent Layer | ARIA, bounded ReAct loop, tool allowlists |
| Desktop Integration | systemd, FUSE, X11, Sway, i3 |
| Terminal | command wrapper, history, recovery, risk preview |
| Sync | LAN discovery, pairing, encrypted channel |
| Testing | pytest, e2e, chaos, soak, gate tests |
| Security Review | Bandit, pip-audit, DAST, secret scanning |
| Packaging | AppImage / .deb Linux packaging |
🧪 Testing Pipeline
flowchart TD
A[Code / Release Candidate] --> B[quick]
B --> C[full]
C --> D[e2e]
D --> E[chaos]
E --> F[soak]
F --> G[security scans]
G --> H[gate]
H --> I{Release status}
I -->|Pass| J[Beta candidate]
I -->|Fail| K[Blocked / Fix required]
style H fill:#111827,stroke:#06B6D4,color:#fff
style J fill:#052e16,stroke:#22C55E,color:#fff
style K fill:#450a0a,stroke:#EF4444,color:#fff
Test scopes
| Scope | Purpose |
|---|---|
quick | Fast smoke checks |
full | Main regression suite |
e2e | End-to-end workflow validation |
chaos | Degraded-state and fault testing |
soak | Long-running stability checks |
gate | Release-readiness validation |
Security review snapshot
| Area | Public status |
|---|---|
| Secret scanning | No public secrets included in this documentation repo |
| DAST | Included in release validation notes |
| Bandit | Findings tracked during hardening |
| pip-audit | Dependency findings tracked during hardening |
| Packaging validation | In progress for beta distribution |
Read more: docs/TESTING_AND_QA.md
🔐 Privacy Boundary
flowchart TD
A[User Desktop] --> B[Local Anion Services]
B --> C[Local Memory]
B --> D[Ollama Local Models]
B --> E[ARIA Tool Guardrails]
E --> F{Sensitive action?}
F -->|No| G[Approved local action]
F -->|Yes| H[User approval required]
B -. optional if configured .-> I[External Services]
style A fill:#020617,stroke:#06B6D4,color:#fff
style B fill:#111827,stroke:#8B5CF6,color:#fff
style C fill:#111827,stroke:#10B981,color:#fff
style H fill:#111827,stroke:#F59E0B,color:#fff
style I fill:#111827,stroke:#EF4444,color:#fff
Anion is designed to keep workflows local by default. External services, if supported in a beta build, should be explicitly configured and documented.
Read more: PRIVACY.md
🧩 Why This Was Technically Interesting
| Challenge | What made it hard |
|---|---|
| Linux desktop context | Needed real OS signals through systemd, FUSE, X11, Sway, and i3 |
| Agentic safety | ARIA had to act through bounded tools, risk tiers, and approvals |
| Real-time state | UI needed live backend state without becoming the source of truth |
| Terminal recovery | Needed deterministic safety checks plus useful recovery suggestions |
| Local memory | Needed useful context without making cloud AI the default dependency |
| Cross-device sync | Needed pairing, encrypted state handoff, and conflict handling |
| Release validation | Needed quick, full, e2e, chaos, soak, security, and gate checks |
📋 Product Status
┌─────────────────────────────────────────────────────────────┐
│ Anion v0.1.0 — Release Candidate / Beta │
├─────────────────────────────────────────────────────────────┤
│ ✅ Feature-complete for current Linux-only scope │
│ 🔄 Dependency CVE remediation │
│ 🔄 Subprocess security audit │
│ 🔄 Packaging validation │
│ 🔄 Public documentation cleanup │
│ │
│ ⚠️ Beta software — intended for Linux power users │
└─────────────────────────────────────────────────────────────┘
🔒 Why the Source Is Private
The Anion source code is private during beta because the project includes security-sensitive local automation logic, Linux desktop integration code, packaging scripts, and hardening work that should be resolved before broader exposure.
| Reason | Detail |
|---|---|
| Security hardening | Known dependency and subprocess findings are tracked before public code release |
| Beta stability | The product is feature-complete for scope but still undergoing packaging and release validation |
| User safety | Local automation and desktop integration require careful review before open distribution |
| Licensing | Source availability will be revisited after security cleanup and licensing decisions |
Source availability will be revisited after security cleanup, packaging validation, and licensing decisions are complete.
📚 Documentation
Architecture + DesignCore Systems |
Operations + QualityUser Docs |
🚀 Early Beta
Anion is currently in private beta.
Early beta is intended for Linux users, developers, terminal-heavy users, local AI users, and people comfortable testing release-candidate software.
Request Beta Access →
Selected testers will receive installation instructions and beta access details by email.
👤 My Role
I designed and built Anion end-to-end.
| Backend architecture | Python services, daemon orchestration, local HTTP/SSE bridge, memory and context systems |
| ARIA assistant | Agent loop, tool schemas, guardrails, privacy redaction, risk tiers, approval flows |
| Desktop shell | Electron/React interface, live dashboard, neural brain visualization, backend state integration |
| Terminal intelligence | Persistent history, recovery engine, destructive-command risk preview |
| Sync system | Pairing flow, encrypted context handoff, conflict handling path |
| Testing and release | Test harness, security scans, soak tests, gate checks, release documentation |
🧭 Repository Purpose
This repo is for:
- public architecture documentation,
- product and feature explanation,
- recruiter/reviewer visibility,
- beta access information,
- diagrams and release notes,
- public issue/feedback collection.
This repo is not:
- the production source repository,
- an open-source codebase,
- a package registry,
- a public installer mirror.
Anion
A local AI operating layer for the Linux desktop.
GitHub · Architecture Docs · Roadmap · Beta Access
Built by Gopal Singh Rajput
Collected info
- ★ 2 stars
- Language: Mermaid
- Source updated: 6/28/2026
Config for your environment
Replace {MCP_ENDPOINT_URL} with this MCP’s endpoint URL (from its repo or docs above). No API key — you connect directly.
Tool
OS
Config file: ~/.cursor/mcp.json
{
"mcpServers": {
"mcp-server": {
"url": "{MCP_ENDPOINT_URL}"
}
}
}Paste into mcpServers in the config file. Restart Cursor after saving.
If this MCP is also published on mcpchannel.ai, you can subscribe from Browse and use the gateway config there instead.