The architecture of OpenCode's persistence and workspace management layers is centered around the relationship between projects, sessions, and sandboxes. Here is a breakdown of the core concepts and data structures.
Architecture
Persistence layer, session hierarchies, and workspace management logic
Understand projects
Projects are identified by the root commit hash of a git repository.
This allows the system to track a project even if the directory is renamed or moved.
The persistence layer stores project metadata in a dedicated table.
This includes the primary worktree path and a list of active sandboxes.
const ProjectTable = sqliteTable("project", {
id: text().primaryKey(),
worktree: text().notNull(),
sandboxes: text({ mode: "json" }).notNull()
})
Organize sessions
Sessions represent individual conversation threads tied to a specific project.
They are organized in a hierarchy using parent identifiers to support forks and subtasks.
Data grows linearly as messages and parts are added to a session.
The schema separates messages from their constituent parts for granular tracking.
Manage workspaces
A workspace consists of a common worktree and one or more sandboxes.
The worktree is the shared git directory, while sandboxes are specific checkouts.
Instances provide the runtime context for a given working directory.
They resolve the relationship between the current path, the project, and the sandbox.
Capture checkpoints
Checkpointing is handled through a revert mechanism stored on the session.
It captures message identifiers and snapshots to allow rolling back state.
const SessionTable = sqliteTable("session", {
id: text().primaryKey(),
revert: text({ mode: "json" }).$type<{
messageID: string
snapshot?: string
}>()
})
Summary fields track file changes and diffs across the session history.
This provides the agent with a compressed view of the current work state.
Partition knowledge
Knowledge is sectioned into hierarchies based on the active agent and session depth.
Primary agents use the full session history as their request context.
Subagents operate in isolated contexts with restricted permissions and specialized instructions.
This prevents context pollution while allowing deep exploration of specific tasks.
I have committed these changes to packages/web/src/content/docs/docs/architecture.mdx.