FAQ

ostk uses optimistic concurrency control. Every file:edit() specifies the text the agent expects. If another agent changed it, the kernel detects the mismatch and resolves it through a 3-tier system: auto-merge for non-overlapping edits, mechanical rebase for nearby edits, and manual escalation for structural conflicts. No locking, no blocking.

One command: curl -fsSL https://ostk.ai/install | sh. The script detects your platform (macOS arm64/x86_64, Linux arm64/x86_64), downloads the correct binary, verifies its GPG signature, and places it in your $PATH. Then run ostk init and ostk boot.

No. The write path is invisible — agents edit files with their normal tools. The OS intercepts writes at the tool layer, coordinates between agents, and maintains an audit trail. Agents never know ostk is there. This is the first of the Five Laws.

Secret values never enter the LLM context. The kernel resolves keys from your platform keychain (macOS Keychain, Linux secret-tool) at call time and injects them via subprocess environment variables. All tool output passes through a masking layer that replaces any secret values before the LLM sees them.

Trust is determined by GPG cross-signatures. T0: your GPG key fingerprint is hardcoded in the kernel trust anchors (full governance — not reachable by ceremony). T1: your key is cross-signed by a T0 holder (write access). T2: GPG key present, not cross-signed (read + narrow write exceptions). T3: no GPG key (boots, reads everything, writes denied by pin caps). Run ostk boot to see your tier.

Yes. ostk coordinates file access across agents through optimistic concurrency. Each agent gets a workspace boundary. Generation counters track every file write. When conflicts occur, the kernel resolves them mechanically — no LLM is called for conflict resolution. In practice, conflicts drop to near zero.

Every agent action is logged to an append-only audit trail (.ostk/journal.jsonl). File edits, shell commands, tool calls, spawns, approvals — all timestamped and attributed. Run ostk os audit check to verify trail integrity. The process table is reconstructible from the audit log at any point.

No. ostk is local-first. Agent coordination happens through local files. The only network calls are to LLM providers when you run agents. The kernel itself is entirely offline. No telemetry, no analytics, no cloud sync.

Agents are ephemeral — crashes are the expected operating condition. The kernel writes drain snapshots at every turn boundary. On daemon restart, fold(journal.jsonl) reconstructs the fleet and rehydrates sessions from snapshots. Mid-flight, the heartbeat monitor detects crashed workers and hot-rehydrates them.

A needle is an atomic, executable work item with acceptance criteria. It is the unit of work in ostk, stored in .ostk/needles/issues.jsonl. Create one with ostk work add --priority P0 "title". Needles have priority tiers (P0-P3), status tracking, and dependency links.

Tack is the operator intent language in the TUI. You type commands into the tack bar: :compile dispatches to the kernel, .? queries the OS through the LLM, →573 references a needle, and bare text is filed as hay (raw unstructured intent for later compilation into needles).

ostk is an OS, not an IDE or agent. It coordinates multiple agents from any provider (Claude, Gemini, Mistral) on the same codebase simultaneously. Cursor and Aider are single-agent tools. Devin is a cloud-hosted agent. ostk runs locally, is agent-agnostic, and provides trust governance, audit trails, and crash recovery that none of these tools offer.