OOOPS

OS Orchestrated Operations

Operate your entire local agent stack from one intelligent desktop.

The idea | Workflow | Product | Architecture | Run locally

---

OOOPS is a local desktop operations layer for agentic tools. It turns installation, inventory, runtime telemetry, release tracking, policy controls, and provider-safe logs into one coherent workspace.

Agent tools are powerful, but their operational surface is scattered. Setup hides in shell commands. Runtime state lives across process monitors and port tables. Provider policy is separated from the action it governs. Release information arrives after the tool has already changed.

OOOPS puts those fragments back into one system. Start with a natural-language request, configure the local stack visually, then inspect every running service and policy from the same desktop context.

The local ops layer

Intent first, operations underneath

OOOPS begins with the way people actually think about local work: a request. Ask it to prepare Ollama, inspect a port, summarize policy activity, or explain what is running. The assistant turns that intent into an operational plan with visible steps, resource context, and a direct path into the working surface.

The interface does not hide the system behind a chat response. Conversation is the entry point. Inventory, status, security, and logs remain the source of operational truth.

One visual language for the whole machine

The workspace uses a quiet sage canvas, compact telemetry, restrained status color, and a persistent navigation rail. Installation intentionally shifts into a warm radial surface so configuration feels distinct without becoming a second product.

Every screen answers one question:

• Chat: What should happen next?
• Inventory: What exists on this Mac?
• Status: What is running right now?
• Release Notes: What changed in the agent toolchain?
• Security: What is allowed to leave the local boundary?
• AI Logs: What happened, and what was redacted?
• Settings: How should the local runtime behave?

From intent to operation

Request -> configure -> observe -> protect

OOOPS follows the natural sequence of local operations:

1. Describe the outcome. Start from a natural-language request instead of searching for installation commands.
2. Shape the local stack. Select a provider and workflow through the radial setup surface.
3. Verify the machine. Read inventory, resources, workers, listeners, and release state in one place.
4. Keep the boundary visible. Review policy gates and provider-safe event records before context leaves the Mac.

The radial selector makes provider setup spatial. Ollama, Claude, Codex, Gemini, and other local or hosted routes sit inside one configuration sequence. Setup mode, tool gateway, and messaging stay visible as the flow advances.

See the machine as a living system

Status is not a pile of dashboard cards. It is a ruled telemetry surface where resource pressure, workers, processes, and loopback listeners share the same reading order.

CPU, memory, and disk move against a deterministic local trend. Worker state explains what the runtime is doing. Listener rows keep 127.0.0.1:49152 and 127.0.0.1:5173 visible as local-only infrastructure rather than invisible implementation detail.

One system, seven surfaces

Inventory Detected runtimes, package managers, agent contents, local notes, and cleanup state.	Security Policy gates for local capture, shell review, provider sharing, raw command text, warnings, and monitoring.

Release Notes A unified feed for Cursor, Claude Code, and Codex with complete change context.	AI Logs Searchable local events with filters, pause control, selected detail, and redaction evidence.

The local boundary is part of the product

OOOPS treats locality as a visible operating rule, not a footnote.

• The FastAPI service binds to 127.0.0.1:49152.
• The desktop renderer binds to 127.0.0.1:5173 during development.
• Provider-bound summaries exclude raw command text and secret-looking values.
• Security controls show whether context is enabled, blocked, redacted, or local only.
• No cloud service or API key is required to bring the full workspace online.

The result is not less capable because it is local. It is easier to trust because the boundary can be inspected from the same surface where the work happens.

Architecture

flowchart LR
    Person["Operator"] --> React["React workspace"]
    React <-->|"HTTP / 127.0.0.1:49152"| API["FastAPI local service"]
    React <-->|"Tauri invoke"| Rust["Rust desktop host"]
    API --> State["Deterministic workflow state"]
    API --> Events["Provider-safe event timeline"]
    Rust --> System["macOS resources and ports"]
    Rust --> Window["Native desktop window"]

Loading

Layer	Responsibility
React 19 + Vite	Product surfaces, interaction state, motion, charts, and local API client
Tauri 2 + Rust	Native desktop host, window lifecycle, real system snapshot, and port probes
FastAPI + Pydantic	Loopback API, typed product data, chat responses, policy state, logs, and install progress
Local launcher	Starts the API first, verifies health, then brings up Tauri or the browser preview

Cursor Hackathon Winner

OOOPS was built for the Cursor Hackathon and selected as a Winner.

The project started from a simple observation: agentic development has rapidly improved the act of writing code, while operating the local agent environment still feels fragmented. OOOPS closes that gap with a desktop-native control plane that can be understood in seconds and explored in depth when something changes.

Its core position is equally simple:

The local agent stack should be operable as a system, not remembered as a collection of commands.

Run OOOPS

Prerequisites

• Node.js 20 or newer
• npm
• Python 3.11 or newer
• uv
• Rust
• Tauri 2 system prerequisites

Install

npm install

uv resolves the Python environment from backend/pyproject.toml when the local service starts.

Start the desktop app

npm run ooops

Start the browser preview

npm run ooops:preview

The launcher waits for http://127.0.0.1:49152/api/health, starts the selected interface, forwards shutdown signals, and cleans up every process it owns. If a healthy OOOPS service already owns the API port, the launcher reuses it without terminating that service on exit.

Validate

npm run build
uv run --project backend --extra test pytest
cargo fmt --manifest-path src-tauri/Cargo.toml --all -- --check
cargo check --manifest-path src-tauri/Cargo.toml
cargo test --manifest-path src-tauri/Cargo.toml --lib

The verified baseline includes:

• Production React bundle
• 8 FastAPI contract tests
• 2 Rust native-command tests
• macOS application bundle
• macOS DMG installer
• Playwright coverage of the primary product surfaces

Repository shape

ooops/
├── assets/readme/          Product screenshots
├── backend/                FastAPI service, typed models, state, and tests
├── public/                 Browser assets
├── scripts/                Local process launcher
├── src/                    React product workspace
├── src-tauri/              Rust desktop host, capabilities, and app icons
├── package.json            Frontend and launch commands
└── README.md               Product story and operating guide

---

OOOPS does not make the local agent stack look simple. It makes the stack legible: first as an intention, then as an operating surface, and finally as an auditable local system.