ostk (kernel)
The central coordinator of the ostk ecosystem. Spawns as a background daemon, virtualizes workspace filesystem boundaries, and orchestrates local agent activities.
License: AGPL-3.0 | Interface: Socket / IPC | Core: Rust (tokio)
OVERVIEW
ostk is the binary that runs when you execute ostk boot. It loads your GPG/Ed25519 identity, opens the shared workspace database, spins up the IPC sockets, and spawns internal drivers. It provides the CLI interface (ostk tack, ostk ps) and acts as the gatekeeper supervising all agent tools. Note that ostk do is deprecated; one-shot prompts are instead routed through ostk tack --run.
OS-LEVEL PROCESS SANDBOXING
To prevent untrusted agent tools or generated code from damaging the host operating system, ostk runs commands inside platform-native sandboxes based on your HUMANFILE capability pins:
macOS Seatbelt
Spawns subprocesses using sandbox-exec, compiling dynamic scheme rules. It strictly restricts read/write operations to the project folder and blocks arbitrary sockets.
Linux Landlock
Applies thread-level kernel restrictions restricting filesystem traversal. Processes cannot walk outside the root workspace path even if run with high shell privileges.
VFS NAMESPACES
The daemon virtualizes filesystem paths using a Virtual Filesystem (VFS) namespace overlay. Directory structures can be mounted with custom rules (read-only, write-ephemeral, or invisible) to isolate the agent:
- Read-Only Mounts: Prevents standard system directories (like
/etcor library frameworks) from being written to. - Write-Ephemeral: Allows writing temporary test files or configurations that are discarded automatically on session shutdown.
- Invisible Writes: Intercepts file creations/mutations, writing them to a hidden local journal until they are approved by the operator.
OPTIMISTIC CONCURRENCY & WAL JOURNALING
When multiple agent instances or tools run simultaneously in the same workspace, they coordinate through the daemon to avoid race conditions:
Optimistic Concurrency Control (OCC)
Every file mutation records its last-modified timestamp. Before writing a replacement chunk, the daemon verifies that the file version has not been incremented by another thread, raising conflicts dynamically.
Write-Ahead Logging (WAL)
All modifications are pre-committed to a structured Write-Ahead Log (.ostk/audit.jsonl) before touching disk blocks. If a subprocess crashed mid-write, the daemon recovers state on the next ostk boot.