Lock File Format
Installed agents are tracked in.opencode/agents/.manifest-lock.json:
Entry Fields
| Field | Type | Description |
|---|---|---|
sha256 | string | Hex digest of file content (required) |
installedAt | ISO 8601 | First install timestamp |
updatedAt | ISO 8601 | Last modification timestamp |
relativePath | string | Path within agents dir (optional, for subagents) |
How Hashing Works
Installation
When you install an agent:- Download content from registry
- Apply permission modifications (if any)
- Compute SHA-256 hash of final content
- Write agent file to disk
- Record hash in lock file
- Reinstalling with different permissions updates the hash
rehashwon’t flag permission changes as modifications- The lock tracks what you installed, not what’s in the registry
Agent States
The lock system detects four agent states:| State | Condition | What it means |
|---|---|---|
installed | File exists, hash matches lock | Agent is current |
outdated | File exists, hash differs | File was modified since install |
new | File missing | Agent not installed yet |
unknown | File exists, no lock entry | Manual install or pre-lock version |
CLI Commands
Verify Integrity
Check installed files against lock hashes:- OK: Hash matches, no changes
- Mismatch: File modified since install (or permissions changed)
- Missing: Lock entry exists but file deleted
0if all OK1if any mismatches or missing files
Rehash Lock File
Rebuild lock from installed files:- Scans
.opencode/agents/for all.mdfiles - Recomputes SHA-256 for each
- Overwrites lock file with fresh entries
- Sets
installedAtandupdatedAtto current time
- Fixing a corrupted lock file
- Adopting lock system after pre-lock installs
- Resetting after manual agent edits
rehash makes that the new baseline.
Update Outdated Agents
Reinstall agents with hash mismatches:- Runs
detectAgentStates()to findoutdatedagents - Downloads fresh copies from registry
- Installs with
--forceto overwrite - Updates lock file with new hashes
Outdated Agent Detection
The lock system powers the--update workflow:
Lock File Integrity
Corruption Handling
If.manifest-lock.json exists but is corrupted (invalid JSON):
- Warning printed to stderr
- Lock file backed up to
.manifest-lock.json.bak - Empty lock object returned
- Next install writes fresh lock
Security Validation
Lock entries are validated on load:- Entry shape: Must have
sha256string - Agent names: Must match
SAFE_NAME_RE(alphanumeric, hyphens, underscores) - Relative paths: No
.., no absolute paths, no leading slashes
Integration with Installer
The installer automatically maintains the lock:- Computes SHA-256 of content
- Updates or creates lock entry
- Preserves
installedAtif entry already exists - Sets
updatedAtto current time - Writes atomically (temp file + rename)
Uninstall
When uninstalling, the lock entry is removed:Filesystem Scanning
The lock system can discover agents not tracked in the manifest:- Symlinks are skipped
- Resolved paths must stay within
base_path - Recursive scan with cycle detection (
ELOOPhandled)
Migration and Bootstrap
For existing installations without a lock file:- Only adds entries for agents not already in lock
- Preserves existing lock entries
- Returns
trueif lock was modified
What Lock Files ARE NOT
❌ Not for supply-chain security The lock file doesn’t verify that downloaded agents match a trusted source. It only detects post-install modifications. Supply-chain trust comes from:- HTTPS download
- Host allowlist (GitHub raw only)
- Manual curation of agent registry
package-lock.json, this doesn’t pin versions. Agents don’t have version numbers — the registry is always “latest”.
❌ Not a substitute for backups
The lock file helps detect changes, but can’t recover lost or corrupted agents. Keep backups or rely on registry as source of truth.
Examples
Detect tampering
Sync modifications
Update workflow
Related
- Permissions — Control agent access
- Architecture — System design and data flow