workbench.tasks-and-sessions

The available source grounding defines a VS Code task chain for preparing and launching a desktop debug session. It does not include the implementation of workbench tasks or sessions, so this page distinguishes the observable launch configuration from behavior that cannot be verified.

Purpose and Scope

This page covers the five tasks visible in the supplied VS Code task configuration: two background preparation tasks, one parallel aggregate, and two alternative Electron launches. The source excerpt is numbered 1–120 but does not identify its repository-relative filename or provide a file-reference base URL. Accordingly, line references below refer to supplied source lines, not clickable repository links. No claims are made about application-level task or session storage, APIs, state transitions, or UI because their implementation is not present in the available grounding.

For application-level task and session behavior, consult the corresponding workbench implementation once its source is available; the VS Code debug-task configuration alone does not establish that behavior.

Overview

The configuration uses VS Code task schema version 2.0.0 (supplied source lines 1–3). Both preparation tasks run Node scripts from the workspace root and remain active in the background. Their problem matchers use output patterns as readiness signals. The aggregate task requests the two preparations in parallel. Either Electron task depends on that aggregate and runs the same launcher script; the host-inspection alternative adds --host-inspect (lines 4–118).

The visible configuration describes developer debug orchestration, not a persisted workbench session model. In particular, isBackground: true and a background problem matcher express how the editor observes a long-running process; they do not prove any application-level session lifecycle.

Architecture

The verified dependency graph is:

• zcode: prepare desktop debug depends on zcode: tsup watch (debug) and zcode: vite dev, with dependsOrder: parallel (lines 59–62).
• zcode: start electron (debug) depends on zcode: prepare desktop debug (lines 64–72).
• zcode: start electron (debug with host inspect) also depends on zcode: prepare desktop debug (lines 92–100).

These are alternative launch tasks, not a chain from one Electron task to the other. All four process tasks invoke node, use ${workspaceFolder} as their working directory, set isBackground: true, and present output in a dedicated panel within the zcode-debug presentation group (lines 4–17, 31–44, 64–77, 92–105). The aggregate task is only a dependency declaration; it does not specify its own command (lines 59–62).

A repository-backed Mermaid diagram cannot be included responsibly: the available excerpt does not provide a repository-relative file path and base URL required to attribute every code block, including Mermaid blocks. The dependency list above represents only verified configuration edges.

Task behavior and readiness

Each process task sets problemMatcher.owner to custom, matches a complete output line with ^(.*)$, and captures it as message: 1. Its background matcher sets activeOnStart: true, beginsPattern: ".", and the task-specific endsPattern in the table (lines 18–29, 45–56, 78–89, 106–117). The configuration therefore declares observable output milestones; whether the scripts actually emit these strings, whether Electron successfully starts, and what follows the debugger-listening message cannot be established without reading the referenced scripts.

Core flow

1. Select one of the two Electron launch tasks. Each declares the aggregate zcode: prepare desktop debug as a dependency (lines 64–72 and 92–100).
2. The aggregate declares the tsup watcher and Vite dev-server tasks as parallel dependencies (lines 59–62).
3. VS Code observes each preparation task through its background problem matcher. The specified completion-of-background patterns are the host watcher message and Vite readiness message, respectively (lines 18–29 and 45–56).
4. The selected Electron task invokes the launcher script through Node; only the host-inspection variant passes --host-inspect (lines 64–70 and 92–98).
5. Its own matcher looks for a debugger-listening message on 127.0.0.1:9231 (lines 78–89 and 106–117).

The source does not show a launch configuration selecting either task, attach behavior, cleanup behavior, or whether VS Code terminates the background processes after debugging.

Usage examples

No code example available. The supplied configuration excerpt has no repository-relative path or runtime file-reference base URL; reproducing it as a code block would violate the requirement for an immediately adjacent, valid source link. The task labels and arguments above are transcribed from the supplied source and can be used to identify the intended VS Code tasks without inventing commands or application APIs.

Configuration and operational notes

The problem matchers rely on exact or regex-matched log output. If the scripts change their readiness wording or never emit a matching line, the configured readiness condition may not be observed; the excerpt does not specify a fallback or timeout. Both Electron variants look for the same debugger address and port in output; this is a matcher pattern, not evidence of a configurable listener or guaranteed binding. No retry policy, session persistence, database, or application-level concurrency controls appear in the supplied source.

Verification boundary

Implementation details not found in source: contents of .vscode/tsup-watch.mjs, .vscode/vite-dev.mjs, and .vscode/start-electron.mjs; launch configurations; workbench task and session services, entities, endpoints, persistence, tests, and application error handling. Document those mechanisms only after examining their actual implementation and cross-references. The available excerpt establishes the debug-task dependency graph and declared readiness patterns, but nothing more.

Related links

No verified documentation paths or repository file-reference URL were provided. See the workbench task and session implementation and the referenced .vscode scripts in the repository for behavior outside this configuration.