Opta Code Desktop · Visual Masterclass

Opta Code
Desktop Masterclass

The definitive visual guide to running, navigating, and mastering the Opta Code native desktop application. Built for visual learners who want to understand the system, not just use it.

Tauri v2 Shell Runtime
React 18 UI Layer
WS + HTTP Daemon Transport
macOS / Win Platforms

What is Opta Code Desktop?

Opta Code Desktop is a native graphical shell built around the same daemon that powers your terminal. It's a stateless viewport into the daemon's brain — it doesn't run inference or orchestrate agents. It shows you what the daemon is doing, in real time, with a polished visual layer.

Tauri v2 React 18 + Vite CLI-compatible Daemon-connected
💡
Key mental model
Think of Code Desktop as a live dashboard panel bolted onto the CLI daemon. Every session you run via opta chat or opta do is visible here, in real time, with zero extra setup.
Code Desktop CAN
  • Show live streaming output and tool calls
  • Browse historical sessions and turns
  • Control daemon lifecycle (start/stop/restart)
  • Export conversations to JSON or Markdown
  • Submit new turns (Chat and Do mode)
Code Desktop CANNOT
  • Run its own inference or load models
  • Work without a running daemon
  • Replace the CLI for power workflows
  • Modify daemon configuration directly
  • Run on a machine without Opta CLI installed

How It All Connects

Code Desktop sits at the top of a three-layer stack. Understanding these layers tells you exactly what to restart when something breaks.

🖥️
Opta Code Desktop
Tauri v2 + React 18
localhost:5173 (web) / native
HTTP REST + WS
⚙️
Opta Daemon
Node.js + Express
127.0.0.1:9999
OpenAI-compat API
🧠
Opta LMX
Python + MLX
192.168.x.x:1234
Native Layer
Rust shell handles OS token storage, window management, and native IPC
Orchestration Layer
Daemon owns sessions, tool permissions, event persistence, and inference proxying
Inference Layer
LMX runs on Apple Silicon (MLX), OpenAI-compatible API, never on your MacBook
text Transport contracts
# Tauri commands (native runtime only) bootstrap_metadata{ host, port, token } secure_store_get → daemon token from OS keyring # HTTP REST (both native + browser/dev mode) GET /v3/sessions → session list POST /v3/sessions → create session POST /v3/sessions/:id/turns → submit turn POST /v3/sessions/:id/stop → cancel run # WebSocket (real-time event stream) ws://127.0.0.1:9999/v3/events?token=<T> # Events: turn.token · turn.done · tool.call · tool.result · session.cancelled

Every Panel, Explained

The interface has three persistent panes. Learn what each surface is for — and you'll never be lost navigating a session.

Opta Code Desktop — refactor-auth-layer
Sessions
refactor-auth-layer
Active · 12 turns
add-pagination-api
Done · 8 turns
debug-deploy-webhook
Done · 5 turns
write-readme-update
Done · 3 turns
Refactor the auth middleware to use the new JWT library and add refresh token rotation
I'll refactor the auth middleware step by step. Let me start by reading the existing implementation.
🔍 read_file · src/middleware/auth.ts pending…
✓ read_file complete · 142 lines 82ms
1,847 tokens 94 tok/s 19.6s 3 tools
Looks good. Now write the updated middleware.
DO MODE ⚡ LMX · Mono512 L2 · Safe
Type a message… ⌘↩ Send
Telemetry
Tok/s
94
VRAM
48%
Context
82%
Daemon
Status ● Running
Port 9999
Uptime 2h 14m
Sessions 4 active
Active Turn
● Streaming…
Elapsed: 00:00:19
📋
Session Rail
Left sidebar lists all daemon sessions. Searchable by title or session ID. Selecting a session loads its full timeline.
⏱️
Timeline View
Chronological turns with user messages, model responses, and tool call/result cards. Virtually-rendered so it never slows down.
✍️
Composer
Smart input with per-turn override pills for mode, model, and permission level. Switch Chat↔Do without leaving the conversation.
📊
Telemetry Panel
Live token velocity, VRAM usage, context fill, and daemon heartbeat. First stop for debugging performance regressions.

Chat Mode vs Do Mode

Code Desktop exposes both interaction modes from the same Composer. The mode pill controls how the daemon orchestrates your turn — not just what gets displayed.

💬
Chat Mode
opta chat · CHAT MODE pill
  • Interactive back-and-forth conversation
  • You approve every tool call before it runs
  • Model streams responses token-by-token
  • Best for exploration, review, and steering
  • No auto-execution of file or shell tools
→ "Explain what this function does and suggest improvements"
Do Mode
opta do "task" · DO MODE pill
  • Autonomous agent loop until task completes
  • Safe tools run automatically (read, search)
  • Dangerous tools need permission (write, exec)
  • Best for well-defined, repeatable tasks
  • Timeline shows full tool call trace
→ "Refactor all API routes to use the new error handler"
💡
Switching mid-session
You can switch modes per turn without creating a new session. Click the mode pill in the Composer to toggle. Chat a few turns to explore, then switch to Do to execute — all in the same session timeline.

Feature Reference

Every capability Code Desktop adds on top of raw CLI access.

🃏
Tool Cards
Every tool call renders as a collapsible card showing tool name, arguments, and result. Expand any card to see the full payload.
📈
Turn Statistics
Each completed turn shows: token count, generation speed (tok/s), elapsed time, and tool call count — at a glance.
📁
Session Export
Export any session as formatted JSON or Markdown. Useful for archiving, bug reports, or sharing session context with teammates.
🔄
Auto-Reconnect
WebSocket drops reconnect with exponential backoff. Code Desktop resumes streaming from your last received event sequence — no state lost.
🔐
Secure Token Storage
Native runtime stores the daemon token in the OS keyring (macOS Keychain / Windows Credential Store). Dev mode falls back to localStorage.
🎛️
Composer Overrides
Inline pills above the input let you override model, mode, and permission level per turn without changing your global configuration.

The Daemon Panel

A dedicated surface for daemon lifecycle management — no terminal required. This is where you restart a stuck daemon, tail logs, and check process health.

Status Metrics
Process state ● Running
PID 84721
Port 9999
Uptime 2h 14m 33s
Active sessions 4
Lifecycle Actions
Stop
Graceful shutdown. Sessions persist to disk.
🔄
Restart
Stop/start cycle. UI auto-reconnects and rotates token.
⌨️
CLI Ops
Handoff to terminal for deep diagnostics.
Live Log Viewer ERROR WARN INFO
14:23:01.812 INFO [session] Session s-a8f2 created 14:23:02.441 INFO [lmx] Model connection established · 192.168.188.11:1234 14:23:04.003 INFO [tools] Tool worker pool ready · 8 workers 14:23:09.224 INFO [session] Turn submitted · session=s-a8f2 model=lmx 14:23:09.891 INFO [stream] Token stream active · 94.2 tok/s 14:23:14.556 INFO [tools] Tool call: read_file · src/middleware/auth.ts 14:23:14.639 INFO [tools] Tool result: read_file · 142 lines · 83ms 14:23:28.110 INFO [session] Turn complete · 1847 tokens · 19.6s
⚠️
Token rotation on restart
Every daemon restart generates a new auth token. In native runtime, Code Desktop updates secure storage automatically. In browser/dev mode, it updates localStorage. Either way, you don't need to do anything manually.

Connection States

The header indicator tells you the current state of the WebSocket connection to the daemon. Know what each state means before you start debugging.

Connected
WebSocket active. Daemon responding to health checks. All features available.
Reconnecting
WebSocket dropped. Attempting reconnect with exponential backoff. Session state preserved.
Disconnected
Multiple attempts failed. Daemon may be stopped. Open Daemon Panel to restart.
🔌
Auto-discovery on startup
On launch, Code Desktop reads ~/.config/opta/ (macOS/Linux) or %APPDATA%\opta\ (Windows) to find the daemon's host, port, and token. If you moved your daemon or changed ports, update these files or re-run opta daemon install.

How Streaming Works

High-throughput local models can produce 90–120 tokens per second. Code Desktop uses two techniques to stay smooth even under that load.

Virtual Rendering
Turn #1 (Unmounted)-210 nodes
Turn #2 (Unmounted)-180 nodes
Turn #12 (Rendered) ←VISIBLE

Off-screen turns are unmounted from the DOM. Scrolling back mounts them on demand. The timeline never slows down no matter how long the session.

Stream Debouncing
Raw tokens
94/s
useStreamingMarkdown · 16ms debounce
DOM updates
60fps

Raw token events are batched with a 16ms debounce before re-rendering. The cursor stays smooth at 60fps regardless of how fast the model is streaming.

Session Triage in 5 Steps

When a session behaves unexpectedly, run this deterministic loop — not ad-hoc clicking. Each step either resolves the issue or narrows the search space.

01
Confirm Route + Permissions
Check the Composer header: which mode is active? Which model? Which permission level? A mismatched pill is the #1 cause of unexpected behaviour. Verify before touching anything else.
02
Check Telemetry Heartbeat
Open the telemetry panel. Is tok/s non-zero? Is the daemon status green? If VRAM is at 100% and tokens have stalled, the model is OOM — unload a model in LMX Dashboard first.
opta status · then check LMX Dashboard at lmx.optalocal.com
03
Find the Divergence Point in the Timeline
Scroll the timeline to the last known-good turn. Look at the event immediately after: was it a model switch, a tool escalation, a context injection, or a daemon reconnect? That event is your root cause candidate.
04
Send a Single Minimal Probe Turn
Send the simplest possible prompt ("What is 2+2?") and watch whether UI rendering, daemon response, and tool flow all complete in a single cycle. This tells you whether the fault is in interaction state, orchestration state, or inference state.
05
Classify the Failure Domain, Then Fix
After the probe, you know exactly which layer failed. UI hydration drift → refresh. WebSocket transport → soft reconnect via Daemon Panel. Daemon task deadlock → restart daemon. Inference issue → unload/reload model in LMX.
opta daemon restart · or use the Daemon Panel in Code Desktop

Recovery Mini-Runbook

When a session fails, preserve evidence before restarting anything. These five actions, in order, contain the failure and prevent recurrence.

Step 01 · Capture
Collect evidence
Note the last timeline event ID, current telemetry metrics, and the last tool invocation. These three artifacts identify the fault layer.
Step 02 · Contain
Stop new risky tasks
Pause non-critical runs. Keep the current session alive if possible — don't restart the daemon until you've captured evidence.
Step 03 · Reconnect
Restore transport first
Use the Daemon Panel to reconnect or soft-restart. Validate with one probe turn before executing any real work.
Step 04 · Replay
Isolate root cause
Rerun the failing prompt with a smaller context window. If it succeeds, the issue was context overflow. If it fails again, the issue is model or tool state.
Step 05 · Document
Write a postmortem note
Record: trigger → symptom → containment → fix. Even one sentence per incident builds a reusable runbook over time.

Keyboard Shortcuts

The interactions that matter most are all reachable without leaving the keyboard.

Submit turn
Cancel active run .
New session N
Toggle Chat / Do M
Search sessions K
Focus composer L
Export session E
Open daemon panel D
🎯
Best practice: CLI + Desktop together
Start and manage the daemon in the CLI. Execute tasks with opta do. Use Code Desktop as your live visual panel. This pairing gives you the speed of terminal + the observability of a GUI — without duplicating effort.

Feature Deep-Dive

Click any feature to explore it in depth. Every capability, every control surface — 16 features across 5 categories.

Opta Code Desktop — Feature Explorer 16 Features
TUI Chat Layout
Interface

"Your coding companion, rendered in pure terminal"

The TUI is Opta's primary interface — a full-screen Ink/React rendering inside your terminal. Three zones: a scrolling message timeline, a live streaming region, and a multi-line composer at the bottom. The layout uses Opta's obsidian glass design system adapted for TTY rendering via Ink's yoga-layout engine.

Terminal Layout
┌─ opta tui ─────────────────────── session #a3b2 ─┐
│ You: Refactor auth middleware to use jose │
│ ◈ Assistant ────────────────────────────────── │
│ I'll update auth.ts to use jose JWT. Let me │
│ start by reading the current implementation… │
│ ▸ tool: read_file("src/middleware/auth.ts") │
│ ▌ Type a message… (Tab: model · ⌘M: menu) [Chat] │
└──────────────────────────────────────────────────┘
Pro Tips
  • Press Tab in the composer to open the Model Picker overlay
  • Ctrl+C cancels an in-progress stream immediately
  • Arrow keys scroll the message timeline without leaving the composer
  • The session ID in the header is your key for daemon API calls
Markdown Renderer
Interface

"Rich text, code blocks, and tables — live in your terminal"

Opta CLI includes a zero-dependency Markdown renderer that converts assistant output to styled terminal content. Code blocks get syntax-highlighted cyan borders with a language label. Inline code uses neon-cyan styling. Headers are bolded with violet accent. Tables auto-align columns. All rendering is stateless and streams token-by-token.

Rendered Output Sample
## Authentication Update
Replace jwt.verify() with jose:
typescript
import { jwtVerify } from 'jose';
const { payload } = await jwtVerify(token, key);
Pro Tips
  • Code blocks render with language labels pulled from the fence marker
  • Tables are automatically padded for terminal-width column alignment
  • Blockquotes render with a violet left-border accent
  • Streaming renders incrementally — output appears as tokens arrive
Model Picker
Interface

"Switch models mid-session with a single keypress"

Press Tab in the TUI composer to open the Model Picker overlay — a searchable list of all models configured across every provider. Recent models appear first. Selection updates the active session immediately with no restart. The current model is always visible in the status bar.

Model Picker Overlay
SELECT MODEL
claude-sonnet-4-6 · LMX local
claude-opus-4-6 · LMX local
claude-sonnet-4-6 · Anthropic cloud
gpt-4o · OpenAI
Pro Tips
  • Type to filter — fuzzy matching on model name and provider
  • LMX models appear first if LMX is healthy
  • The picked model persists for the current session only
  • Use opta config set default-model to change the session default
Chat vs Do Modes
Interface

"Two modes: think with it, or let it act"

Chat mode is conversational — you exchange messages and tool calls require your approval. Do mode (opta do) is agentic — the model orchestrates a full task loop: reads files, edits code, runs commands, browses the web, and iterates until done. The mode pill in the composer switches instantly, mid-session.

Mode Comparison
CHAT
✓ Conversational
✓ Approval gate
✓ Step-by-step
✓ Explain first
DO
✓ Autonomous
✓ Auto-approve safe
✓ Multi-step
✓ Timeline view
Pro Tips
  • Start in Chat to explore, switch to Do when the plan is clear
  • Do mode respects permission policies — write once, reuse across sessions
  • Ctrl+C pauses the loop (not kills it) — you can resume
  • opta do "task" starts directly in agentic mode from the shell
Opta Menu ⌘M
Interface

"Every command, one key away"

Press ⌘M to open the Opta Menu — a searchable command palette with all slash commands, session actions, settings shortcuts, and model controls. Navigate by arrow keys or type to fuzzy-filter. Selecting executes immediately or prefills the composer.

Menu Overlay
OPTA MENU
/clear · Clear session history
/compact · Compress context window
/model · Open model picker
/settings · Open settings overlay
/export · Export as markdown
Pro Tips
  • Type / in the composer to jump directly to the command palette
  • Recently used commands float to the top of the list
  • /compact compresses context — essential for long sessions
  • Custom commands can be registered in ~/.config/opta/commands/
Daemon Connection
Daemon

"The local HTTP backbone powering every session"

The Opta Daemon runs at 127.0.0.1:9999 and exposes an HTTP v3 REST API plus WebSocket streaming. CLI, Code Desktop, and the LMX Dashboard all connect to it. HTTP uses Bearer token auth; WebSocket uses ?token=T query param. The daemon auto-starts when you run any opta command.

Connection Architecture
opta tui
│ HTTP/WS
daemon 127.0.0.1:9999
│ OpenAI API
LMX 192.168.188.11:1234
Pro Tips
  • opta daemon status checks if the daemon is running and shows its PID
  • opta daemon install registers a launchd/systemd service for auto-start
  • Daemon token lives at ~/.config/opta/daemon/token
  • Multiple CLI instances share one daemon — sessions are isolated by ID
Session Store
Daemon

"Every conversation, safely persisted to JSONL"

Sessions are stored as append-only JSONL files under ~/.config/opta/daemon/sessions/. Each line is a timestamped event envelope. Sessions survive daemon restarts and can be replayed from any point using the event cursor (afterSeq). Use opta sessions list to browse all sessions with metadata.

JSONL Event Format
~/.config/opta/daemon/sessions/a3b2c1.jsonl
{"seq":1,"event":"session.start","ts":"2026-03-06…"}
{"seq":2,"event":"turn.start","role":"user","text":"…"}
{"seq":3,"event":"turn.token","delta":"I'll ","model":"…"}
{"seq":5,"event":"tool.call","name":"read_file","args":{…}}
{"seq":7,"event":"turn.done","tokens":428,"elapsed":3.2}
Pro Tips
  • Session files are human-readable — pipe through jq for inspection
  • Resume any session with opta tui --session <id>
  • Export to markdown with opta sessions export <id>
  • Sessions are never auto-deleted — archive with opta sessions prune
WebSocket Event Streaming
Daemon

"Real-time tokens, tool calls, and turn events over WS"

Connect to ws://127.0.0.1:9999/v3/sessions/{id}/stream for live events. Events include turn.token (each streaming token), turn.done (final stats with token counts and speed), tool.call, tool.result, and turn.error. Reconnect with afterSeq to resume without re-delivery.

Live Event Stream
WS ws://127.0.0.1:9999/v3/sessions/a3b2/stream
turn.token"I'll update"
tool.callread_file(auth.ts)
turn.done428 tok · 3.2s · 134 t/s
Pro Tips
  • Store lastReceivedSeq on disconnect; pass as afterSeq on reconnect
  • turn.done includes tokens, elapsed, and tokensPerSec
  • Code Desktop subscribes to this stream for its live UI updates
  • Third-party tools can build on this API — see the daemon interop contract
Tool Dispatch
Daemon

"Execute files, run commands, browse — with approval gates"

When the model requests a tool call, the daemon routes it through the permission gate before executing. Read operations (read_file, list_dir) auto-approve. Write/execute operations (write_file, run_command, browser_navigate) require confirmation unless a policy grants them. Tool results stream back to the model in the same turn.

Approval Gate
Tool Request Received:
⚙ run_command
cmd: npm run test · cwd: …/project
Allow
Deny
Always Allow
Pro Tips
  • "Always Allow" adds a persistent policy entry for that tool
  • In Do mode, safe read tools auto-approve without prompting
  • Tool calls run in parallel when the model requests multiple (up to 8 concurrent)
  • View the full tool call log with opta sessions tools <id>
LMX Routing
Intelligence

"Your Mac Studio as an always-on inference engine"

When LMX is configured, requests route to 192.168.188.11:1234 — your Mac Studio running MLX models. The daemon caches LMX preflight health checks for 10 seconds. If LMX is unreachable, the daemon automatically falls back to the configured cloud provider with no user action required.

Routing Decision
Request: claude-sonnet-4-6
LMX healthy ✓ 192.168.188.11:1234
preflight cached 10s
LMX offline Anthropic cloud fallback
Pro Tips
  • LMX serves OpenAI-compatible /v1/chat/completions — any model name works
  • Set OPTA_LMX_HOST to override the default 192.168.188.11
  • Check LMX health with opta doctor — includes LMX latency ping
  • LMX runs on Mono512 (Mac Studio M3 Ultra, 512GB RAM) for peak throughput
Provider Manager
Intelligence

"LMX local, Anthropic cloud, OpenAI — one unified router"

The Provider Manager normalizes requests across LMX, Anthropic, and OpenAI-compatible providers. It handles streaming format differences, token counting normalization, and provider-specific error codes. Switching providers only requires changing the model name — no API surface changes in your session or daemon code.

Provider Registry
LMX (local)● active
Anthropic● standby
OpenAI○ configured
Pro Tips
  • Provider priority: LMX first (if healthy), then cloud fallback order
  • Add providers with opta config add-provider
  • Each provider credential lives in the Vault — never in config files
  • Provider normalization means the same streaming code works for all
Extended Thinking
Intelligence

"Watch the model reason before it responds"

For supported models (Claude 3.7+ and compatible LMX models), Opta streams thinking blocks interleaved with response tokens. Thinking blocks appear with an indented, muted violet treatment — collapsible via a toggle key. The TUI tracks thinking token counts separately in the turn stats so you can see the reasoning overhead.

Thinking Block
◈ thinking · 312 tokens
The user wants to refactor auth middleware.
Plan: 1) read current impl, 2) find jwt.verify,
3) replace with jose, 4) update imports…
◈ Assistant
I'll update the middleware to use jose. Let me start by reading the current implementation…
Pro Tips
  • Enable with opta config set thinking true for a session
  • Thinking tokens count toward context — monitor for long sessions
  • Collapse thinking blocks with the toggle to reduce visual noise
  • Significantly improves accuracy on complex multi-step reasoning tasks
Browser Automation
Automation

"Peekaboo: full web control via MCP"

Opta integrates with Peekaboo — an MCP server bridging to Playwright. When enabled, the model can navigate URLs, click elements, fill forms, take screenshots, extract page content, and evaluate JavaScript. Browser sessions are sandboxed per agent loop and tracked in the session store alongside other tool calls.

Available Browser Tools
browser_navigate"https://docs.example.com"
browser_snapshot→ accessibility tree
browser_click"[data-testid=submit]"
browser_fill_form{selector, value}
browser_screenshot→ PNG to session store
Pro Tips
  • Enable with opta config set mcp.peekaboo true
  • Browser sessions are sandboxed — no persistent cookies between loops
  • Use browser_snapshot for DOM analysis before browser_click
  • Screenshots saved to ~/.config/opta/browser-snapshots/ for review
Agentic Loop
Automation

"Multi-step autonomous task execution"

In Do mode, the model enters an agent loop: generate → tool calls → results → generate again, until the task is complete or a step limit is hit. The loop surfaces a live progress timeline in the TUI showing each step, its tool calls, and current status. Loops can be paused or cancelled at any point.

Loop Timeline
Step 1: Read auth middleware
Step 2: Identify jwt.verify calls (3 found)
Step 3: Rewriting with jose…
Step 4: Run tests
Step 5: Update imports
Pro Tips
  • Set opta config set max-steps 20 to adjust the step limit
  • The model self-corrects when tool calls fail — review in the timeline
  • Pause with Ctrl+C — progress is saved, resume with opta tui --session <id>
  • Use opta do --watch for desktop notifications on completion
Credential Vault
Security

"API keys stored in OS keychain, never in plaintext"

The Vault stores all credentials — API keys, bearer tokens, provider secrets — in the OS-native keychain. macOS Keychain on macOS, DPAPI/Credential Manager on Windows. Keys are retrieved at runtime and never written to config files or logs. The opta account command manages vault entries with full add/list/remove support.

Vault Operations
$ opta account add anthropic
Enter API key: ••••••••••••••
✓ Stored in macOS Keychain
$ opta account list
anthropic sk-ant-••••3f2a
lmx-local opta_••••••••
openai sk-••••4b1c
Pro Tips
  • Keys are scoped to your OS user account — inaccessible to other users
  • opta account rotate anthropic replaces a key without interrupting active sessions
  • Never set API keys as environment variables — the Vault is more secure
  • Vault entries sync to other devices via the Opta Accounts sync layer
Permission Gates
Security

"Fine-grained control over every tool the model can invoke"

Every tool is categorized by risk level. Read operations always auto-approve. Write/execute operations require confirmation or a matching policy. Policy files in ~/.config/opta/policies/ can pre-approve specific tools, enabling fully autonomous runs in trusted project environments without per-call prompts.

Permission Matrix
TOOL
DEFAULT
read_file, list_dir
✓ auto
search_files, grep
✓ auto
write_file, edit_file
⚠ prompt
run_command
✗ deny
browser_navigate
⚠ prompt
Pro Tips
  • Create a project policy at .opta/policy.yaml to allow tools per-project
  • opta doctor --policy validates your policy files for syntax errors
  • Policies stack: project → user → defaults (project wins on conflict)
  • In CI/CD, set OPTA_POLICY=unrestricted for fully autonomous operation