FAQ

CAS edits made through ostk fs_ops include the text the agent expects. If the file changed, non-overlapping edits can auto-merge, nearby edits return a suggested merge, and structural conflicts fail for review. Native client writes and raw shell writes bypass this CAS contract.

One command: curl -fsSL https://ostk.ai/install | sh. The script detects your supported platform, downloads the matching release artifact, applies the release verification path, and places the binary in your $PATH. Then run ostk init and ostk boot.

You keep the client UI you already use, but the integration must be configured. MCP-capable clients launch ostk connect and use the ostk-namespaced tools for audited reads, CAS edits, and policy checks. A client's native filesystem or shell tools remain outside those guarantees.

On supported kernel-mediated paths, ostk resolves keys at call time, avoids placing the value in the prompt, and masks known values in returned output. Native shell tools, external services, and any process outside the ostk boundary still need their own secret-handling controls.

Boot resolves HUMANFILE SIGN evidence and a verified primefile first, with legacy GPG identity as a fallback. That produces a T0–T3 default posture for kernel-mediated operations: full governance, endorsed source work with guardrails, read-oriented access, or anonymous write denial. Run ostk boot to see the resolved tier and evidence.

Your project files, Git history, tasks, decisions, local audit records, and configured recall sources stay in inspectable storage you control. You can change the model, provider, router, or harness without migrating that continuity layer, while recognizing that each integration exposes a different set of ostk capabilities.

Kernel-mediated tool dispatches append timestamped, attributed rows to .ostk/journal.jsonl. Rows are hash-chained and are Ed25519-signed when a signing key is available. Native client actions that bypass ostk do not become ostk audit rows; inspect and verify the journal when audit coverage matters.

ostk is local-first by custody: canonical project state and local context pages stay on disk, with no required ostk account or hosted control plane. Configured model providers and network tools can still use the network. Anthropic file uploads are an optional context-efficiency upgrade on compatible routes, not a requirement or the continuity boundary; other routes can keep the same paging workflow local.

For anchored ostk-managed sessions, turn boundaries write best-effort local drain snapshots. On restart, durable registries rebuild from their local JSONL sources and eligible managed sessions can rehydrate from a compatible snapshot. Work after the last completed snapshot, runtime-only state, and sessions owned by an external harness have separate recovery boundaries.

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 a project-state and coordination layer, not an IDE or model. Verified integrations can use the same local task, decision, audit, and CAS surfaces through ostk. Provider routes and external harnesses have separate compatibility boundaries, so check the support matrix instead of assuming every client or model behaves identically.