How Ghosthread works
Every action passes through a four-stage pipeline. No stage touches your cursor, focus, or clipboard.
You describe the outcome
Type a plain-English instruction in the Mission Control dashboard, or trigger it from a hotkey. Ghosthread never needs you to write code, record macros, or pick coordinates.
> "Triage unread WhatsApp messages and draft replies under 3 sentences"
The DAG engine decomposes it
Your request splits into isolated nodes on a directed acyclic graph. Each node does one thing. Failed nodes retry locally or fall back to a safer path — the whole plan never collapses from one bad step.
[PLAN] ├─ node:read_unread_badges ✓ 142ms ├─ node:ocr_window_capture ✓ 89ms ├─ node:classify_priority ✓ 210ms ├─ node:draft_replies ✓ 640ms └─ node:stage_for_review ✓ 12ms [PLAN] 5/5 nodes green · 1.09s
Off-screen, in background threads
Actions are dispatched via PostMessageW to window handles directly. Windows don't need to be visible, focused, or on top. Your mouse keeps moving. Your typing keeps landing. Your clipboard stays intact.
Zero OS-level input injection
No foreground window raises
Non-destructive data bus
You get a signed receipt
Every run writes an immutable record to the local WAL-mode SQLite vault: which nodes fired, what they touched, what they produced, how long each took. Nothing leaves your machine unless you explicitly export it.
What could go wrong — and what stops it
Ghosthread assumes hostile environments. Every stage has a hard boundary.
- ▸Directory fence:
C:\Windows,System32,Program Filesare read-only at the kernel level - ▸DLP scanner: regex detection blocks API keys, tokens, and absolute paths from leaving your machine
- ▸Cascade failure halt: one anomalous node aborts downstream siblings before damage spreads
- ▸Recycle-bin routing: files are never destroyed — they go to native Windows Recycle Bin
- ▸Local-only vault: state memories stay in SQLite on your disk. Opt-in export only.
Windows 11 · Beta cohorts rolling out now