Interlock

Workspace status, a Recovery Inbox for everything that changed, and verified filesystem recovery driven by the local Interlock V6 engine — a VS Code companion to the Interlock repository.

This extension is a local control panel, not a recovery engine. Every read and every state change is performed by the Interlock engine itself, invoked through a small Python bridge that ships inside this extension. The extension contains no recovery logic of its own.

What it does

The Recovery Inbox

The Recover button in the sidebar opens the Recovery Inbox — a workspace tab that answers the question "what changed here, and what can actually be restored?":

• Discovery classifies every stored baseline against the file on disk (unchanged / modified / deleted / unreadable), validates the stored evidence against its recorded SHA-256, and lists files that changed after the last capture but have no baseline at all. It writes nothing, and it reports partial coverage honestly (ignored directories, policy exclusions, files it could not read) instead of claiming a complete scan.
• Eligibility comes from the engine. Every changed file with usable evidence is assessed by the engine itself; a file is called Recoverable only when the engine confirms the recovery would succeed with no conflict and no drift.
• Selection works per file, per folder, per filter and for every currently eligible changed file. Ineligible files may stay selected, but they are explained and excluded from the run.
• Recover Selected (N) revalidates the selection, builds a fresh engine plan for every candidate, and shows the exact scope: the files that will be recovered, every exclusion with its reason, and the warnings that matter. For a single file the flow goes straight to the approval dialog.
• Recover All Eligible Changed Files covers exactly the changed files with verified evidence that pass the engine's checks — never unchanged files, never files without a baseline, never a file with a conflict.
• Nothing is written before an explicit confirmation. After the confirmation every file is revalidated again (baseline, evidence, current bytes) immediately before it is written, the real approver identity is recorded, and the result is reported per file as Recovered, Skipped, Failed or Needs attention. A file is only called Recovered when the engine restored the captured bytes and the extension re-checked the hash independently.

The inbox is also reachable from the command palette (Interlock: Open Recovery Inbox); the sidebar Recover button is the convenient entry point to the same tab.

The Status & Recovery activity-bar sidebar is a compact (~260–350 px) security dashboard:

• Header — Interlock shield, wordmark, and refresh / settings actions.
• Engine status card — engine availability, Python version, and the engine's independent platform verdict, each shown as its own state. The status indicator turns green only when the engine genuinely reported available; "not checked yet" is shown until a real probe has run.
• Workspace card — the workspace folder name (the full path stays in a tooltip), confinement status, baseline count, and the read-only git signal.
• Actions — Analyze Workspace is the single highlighted primary action, followed by the inspection/preview/baseline actions, then the approval-gated Apply Recovery (visually separated, amber, marked "approval"), and Verify Recovery last. Recovery is never presented as one-click.
• Verification summary — exactly one accurate state: passed, failed, or "no verification recorded". Nothing is ever fabricated.
• Warnings & errors, Recent incidents, and Documentation — collapsible sections whose counts come from real data; incident history is reported as genuinely unavailable (the engine records none) rather than invented.

The view honours prefers-reduced-motion, is fully keyboard navigable, and uses a restrictive content-security-policy (nonce-only style/script, no external resources, no inline event handlers). To inspect the layout without installing anything, generate the static preview from the production renderer:

npm run compile && node test/visual/generate-preview.js
# then open test/visual/preview.html in a browser

Safety boundaries (enforced in code, not by convention)

• Approval-gated writes. execute refuses to run without both a recorded approver and a preview-time evidence file; the extension always shows the preview diff first, then requires a modal confirmation and a typed approver identity (recorded in the engine's result).
• Conflict guard. Evidence is captured at preview time and re-verified at execute time (seal checked with the engine's own compute_evidence_hash_v2). If a human edits the file after the preview, the execute is refused and the human's edit is left untouched.
• Workspace confinement. Resources must be workspace-relative; parent traversal, absolute paths, UNC paths, and drive letters are rejected before the engine is even called — and the engine refuses them again.
• No shell strings. Every bridge call is spawned with an argument array (shell: false); a subprocess receives a minimal allow-listed environment, never your full process.env.
• Honest success. The extension reports success only when the engine reported success and verification confirmed a byte-exact restore. Refusals, timeouts, and verification failures are reported distinctly — never as "done".
• Secret-safe logging. Everything written to the output channel passes through a redactor (bearer tokens, JWTs, password=/token= assignments, PEM private keys, AWS key ids).
• No telemetry, no network calls. The extension talks only to a local Python process. Nothing is uploaded; no analytics exist.

Platform support (two different claims)

• The extension package is plain TypeScript/Node and installs wherever VS Code runs (Windows, macOS, Linux).

• The Interlock engine has its own, narrower support matrix. The sidebar and Check Status always show the engine's verdict separately:

  Engine environment	Status
  Windows x64 + NTFS (bundled runtime ships; no Python install needed)	TESTED — PRIMARY (the recorded validation environment)
  Windows ARM64	UNTESTED
  macOS arm64	DECLARED — CI PENDING
  macOS Intel	UNSUPPORTED (dependency-blocked)
  Linux x64	DECLARED — CI PENDING
  FAT32/exFAT/network drives	UNSUPPORTED (no atomic-replace guarantee)

"Installs here" is never presented as "validated here".

Requirements

Zero-configuration path (Windows x64): nothing beyond VS Code 1.85+. This build ships a bundled, SHA-256-verified CPython 3.11 runtime and the engine files inside the VSIX, so the first use installs and health-checks the engine automatically - no Python install, no repository checkout, no virtual environment, no pip, and no settings to configure.

Developer / other-platform path: on platforms with no bundled runtime (macOS, Linux, Windows ARM64) the extension instead detects a system Python 3.11-3.14 and either uses a local engine checkout or tells you exactly what is missing. interlock.pythonPath / interlock.engineRoot remain available as optional overrides and always win over automatic discovery.

The bundled runtime is provisioned at build time by tools/provision-runtime.js from a pinned, hash-verified python-build-standalone release; nothing is ever downloaded when a user installs the VSIX.

Install (local VSIX)

code --install-extension interlock-vscode-0.1.0.vsix

Then open the Interlock sidebar (activity bar → Interlock) and run Interlock: Check Installation.

Settings

Known limitations (stated honestly)

• Incident history is unavailable. The current engine exposes no incident store, so Check Status reports incident history: unavailable rather than inventing records.
• git status in the sidebar is a plain git signal, not an engine incident, and is labelled as such.
• Baselines include file content and are therefore stored only in the extension's private storage (globalStorageUri), never inside your workspace, and never echoed to the log.
• Recovery targets a single file per run — the scope the engine's adapter supports and verifies today.
• Platform coverage is limited to the matrix above. Nothing here compensates for an environment the engine has not validated.

Development

npm install
npm run typecheck     # tsc --noEmit
npm run lint          # eslint
npm run test:unit     # 86 unit tests (mocha)
npm run compile

Real-engine integration tests (uses the actual engine, no mocks — creates and removes its own temporary workspace):

.venv\Scripts\python.exe extensions\vscode\test\integration\bridge_integration.py
# → passed=52 failed=0

Package a VSIX:

npm run package       # vsce package --no-dependencies

License

See LICENSE.md. Repository: interlock219-beep/INTERLOCK-V4.