Files
openchamber/packages/vscode/src/DOCUMENTATION.md
T
Bohdan Triapitsyn 85400459e9 perf: overhaul session loading, caching, and runtime isolation (#2360)
Improve OpenChamber responsiveness under large session workloads while fixing
cache, synchronization, and persistence correctness across runtimes, projects,
directories, and worktrees.

- prioritize selected and visible sessions during bootstrap and defer
  non-critical enrichment work
- reduce redundant message loading, event processing, store publication, and
  hidden sidebar work
- prevent stale session and message requests from overwriting newer
  authoritative state
- preserve existing data when authoritative fetches fail instead of treating
  failures as successful empty responses
- scope session materialization, messages, drafts, queues, todos, pins,
  permissions, folders, tabs, Git state, and pull request data by runtime and
  directory identity
- harden runtime switching, reconnect, cleanup, mutation reconciliation, and
  persisted-state ordering
- preserve live subagent Task linkage when metadata arrives after an older
  message request or while streaming parts are suspended
- coalesce overlapping tail refreshes without losing newer refresh demand
- improve cold-session loading by moving deferrable work out of the critical
  bootstrap path
- isolate URL authentication, mobile credentials, native secrets, and other
  runtime-owned state across endpoint changes
- bound long-lived caches and remove avoidable allocations from event and
  rendering hot paths
- limit virtualization to archive collections where it improves rendering
  without disrupting active sidebar layout
- stabilize session folders, pin ordering, expanded state, and persisted
  sidebar behavior
- open skill files through the same secure editor and outside-workspace grant
  flow used by file navigation, including worktree sessions
- expand regression coverage for stale completions, runtime collisions,
  reconnect behavior, persistence races, authoritative empty results, and
  subagent refresh ordering
- document the updated synchronization, cache ownership, performance, and
  runtime-isolation invariants
2026-07-21 20:52:20 +03:00

3.4 KiB

VS Code Backend Modules

This document describes backend runtime modules used by the VS Code extension bridge (packages/vscode/src/bridge.ts).

Purpose

Keep bridge.ts as a thin orchestration layer that delegates message handling to cohesive domain runtimes while preserving API behavior.

Runtime modules

  • bridge.ts

    • Entry orchestration layer for bridge messages.
    • Delegates to specialized runtimes in order and handles only unmatched fallthrough cases.
  • bridge-git-runtime.ts

    • Standard Git message handlers.
  • bridge-git-special-runtime.ts

    • Specialized Git flows (pr-description, conflict-details) and generation helpers.
  • bridge-git-process-runtime.ts

    • Git process execution and environment setup (execGit), including SSH agent socket resolution.
  • gitService.ts

    • Owns VS Code Git and worktree operations.
    • Fast worktree creation reports bootstrap phases explicitly: directory-created, then git-ready after Git population/upstream work, and setup-ready after setup commands. Existing worktrees without tracked bootstrap state fall back to ready/setup-ready; shared webview consumers also accept legacy responses without phase.
    • Worktree removal waits for an active create/bootstrap task for the same directory so background Git and setup work cannot race deletion or restore stale bootstrap state.
  • bridge-fs-runtime.ts

    • Bridge handlers for filesystem-related message routes.
    • Uses shared FS helpers via injected dependencies.
  • bridge-fs-helpers-runtime.ts

    • Filesystem/path/search helper functions:
      • path normalization and resolution
      • directory listing
      • file search
      • file read path safety checks
      • dropped-file parsing and attachment reading
      • models metadata fetch helper
  • bridge-localfs-proxy-runtime.ts

    • Local /api/fs/read and /api/fs/raw proxy helpers and shared proxy utility helpers.
  • bridge-proxy-runtime.ts

    • Proxy route handlers (api:proxy, api:session:message) with injected helper dependencies.
  • bridge-config-runtime.ts

    • Config and skills message handlers (api:config/*).
    • Includes OpenCode resolution diagnostics parity handler used by shared UI (/api/config/opencode-resolution).
  • bridge-settings-runtime.ts

    • Settings read/write and OpenCode skills discovery via API for bridge consumers.
  • bridge-system-runtime.ts

    • System/editor/provider/quota/notification/update-check message handlers.
    • Includes session activity snapshot bridge handler used by webview parity routes (/api/session-activity).
    • Includes Zen utility model parity handler used by shared notification settings (/api/zen/models).
  • bridge-permission-auto-accept-runtime.ts

    • Owns the persisted VS Code permission auto-accept policy and its GET/PUT bridge contract.
    • Serializes reads and read-modify-write updates, persists a monotonic policy revision, and broadcasts the exact committed snapshot to every active OpenChamber webview. Permission replies remain foreground UI-owned because VS Code does not run the OpenChamber server runtime.

Extension guideline

When adding new bridge route families:

  1. Prefer creating or extending a domain runtime module under packages/vscode/src/bridge-*-runtime.ts.
  2. Keep bridge.ts focused on delegation order and minimal fallthrough behavior.
  3. Inject dependencies into runtimes instead of reaching into unrelated modules directly.