Code OSS Launch & Debug
Launch a built-from-source VS Code with isolated profiles, Playwright control, and multi-process debugging ports.
The evidence shows isolated temporary user-data, extensions, and shared-data directories, umask 077, and explicit disclosure that authentication material from the OS keychain and User/globalStorage is preserved; the source profile is not mutated and copy exclusions are documented. Points are deducted because authenticated state is copied by default, the OS keychain remains shared, startup may download/build over the network, and there is no explicit pre-launch confirmation or automatic cleanup/rollback mechanism.
SKILL.md and launch.sh are largely consistent about arguments, ports, JSON output, timeouts, logging, and failure exits, with troubleshooting for missing builds, unavailable CDP, wrong targets, and Monaco input failures. Points are deducted because nothing was executed, no dedicated tests for the launcher's key paths are shown, port selection has a theoretical race, and failures in external tools or the build environment remain user-debugged.
The audience, scenarios, parameters, Playwright/dap-cli integration, Agents-window differences, and platform boundary are documented; Chinese paste handling is mentioned. Points are deducted because Windows is unsupported, network reachability and mainland-China compatibility for authentication, npm, Electron, Playwright, and dap-cli are not established, and semantic triggering still relies substantially on user judgment.
The documentation covers prerequisites, launch flags, copied data, port meanings, examples, parallel use, restart, cleanup, and troubleshooting; repository evidence supplies MIT licensing, Microsoft attribution, a version, and maintenance channels. Points are deducted because the skill has no independent version, changelog, explicit maintainer, or clear update path, and dependency installation guidance is not fully centralized.
The skill clearly produces machine-readable JSON and offers isolated launching, dynamic debug ports, CDP driving, debugger attachment, and a Monaco paste helper for the core UI-automation and debugging tasks. Under static calibration the score is capped at 7; points are deducted because execution was not performed and results depend on a complete build, authentication setup, system tools, and external services, with some failures requiring manual recovery.
The scripts, command examples, diagnostics, and JSON schema make important behavior auditable, while the repository includes general CI workflows and test scripts. Points are deducted because the supplied CI does not cover this skill's launcher, authentication copying, port isolation, or Monaco-helper paths, and claims such as live testing cannot be independently reproduced in this static review, so the score stays within the static limit.
- The launcher copies authenticated VS Code state and continues using the current user's OS keychain; use only after reviewing temporary-directory permissions, credential exposure, and local-process visibility.
- Cleanup relies on manual kill and rm -rf commands, so abnormal exits may leave temporary directories containing sensitive state.
- The core flow depends on macOS/Linux, Node, rsync, curl, npm/Electron/Playwright downloads, and potentially external authentication services; mainland-China network reachability is unverified.
- This was a static review only; actual launch, port isolation, authentication, and Monaco paste behavior were not executed.
What does this skill do, and when should you use it?
This is the single skill at .agents/skills/launch/ in the microsoft/vscode repository. It launches a Code OSS build from sources by cloning an authenticated user-data directory into a temporary profile and assigning isolated ports and directories. Once the renderer's CDP endpoint responds, it prints JSON containing the renderer, extension-host, main-process, and Agent Host ports for @playwright/cli and dap-cli. It fits VS Code development, UI and chat flows, screenshots, and breakpoint debugging, but requires a complete build environment and an authenticated source profile on macOS or Linux.
The skill runs scripts/launch.sh relative to the skill directory. The launcher reads the VS Code checkout and source user-data directory, then copies authentication-related state into a temporary directory; slim mode excludes workspace storage, history, logs, caches, and other regenerable data. Each launch receives isolated user-data, extensions, shared-data, and run directories, along with free CDP, extension-host, main-process, and Agent Host inspection ports. After the renderer CDP endpoint is available, the launcher writes a JSON record containing the process ID, ports, directories, log path, repository, and Agents-window state. The instructions also cover attaching @playwright/cli, listing or selecting Electron targets, taking snapshots and screenshots, pasting text into Monaco through the supplied helper, and attaching dap-cli to the relevant Node inspection port.
- A VS Code contributor needs to run a complete source build and inspect the workbench through CDP.
- A test engineer needs to automate chat or Agents-window flows, verify UI behavior, and retain screenshots.
- A debugger needs breakpoints in the renderer, extension host, Electron main process, or Agent Host.
- An engineering team needs several isolated Code OSS instances on one machine without profile, port, or shared-database collisions.
What are this skill's strengths and limitations?
- The launcher waits for the renderer CDP endpoint before printing JSON, so callers generally do not need a retry loop.
- Fresh temporary profiles, extension directories, shared-data directories, and ports make concurrent instances practical.
- UI driving with @playwright/cli and Node debugging with dap-cli can target the same running window.
- Slim profile copying preserves authentication-related state while omitting workspace state, caches, logs, and other large transient data.
- Only macOS and Linux are explicitly supported; the material provides no Windows support evidence.
- It requires installed dependencies, a full VS Code build including built-in extensions, and an authenticated Code OSS source profile.
- The default extensions directory is empty, so third-party extensions are not present unless --clone-extensions is used.
- The workflow depends on a shell, local filesystem access, and several command-line tools; dap-cli is not supplied by the launcher.
- Native operating-system file dialogs cannot be driven through @playwright/cli over CDP, so each throwaway profile enables VS Code's simple dialog setting.
- No standalone test suite or cross-platform validation results are provided in the supplied material.
How do you install this skill?
The supplied materials place the skill at .agents/skills/launch/ but do not document a standalone installation command or package installation flow. Before use, install dependencies in the VS Code checkout with npm install if node_modules is missing, then run npm run compile or npm run watch to build the full client and built-in extensions under extensions/. Prepare an authenticated Code OSS user-data directory as the launch source. Debugger use additionally requires dap-cli on PATH; the material points to https://github.com/roblourens/dap-cli when that tool is unavailable.
How do you use this skill?
Set LAUNCH to scripts/launch.sh in the directory containing this SKILL.md, for example LAUNCH=<directory containing SKILL.md>/scripts/launch.sh. Run INFO=$("$LAUNCH" | tail -n1), then read the CDP port with jq -r .cdpPort <<<"$INFO" and attach using npx @playwright/cli -s=UNIQUE_SESSION attach --cdp=http://127.0.0.1:$CDP. Use "$LAUNCH" --agents for an Agents window, --source-user-data-dir <path> for a different authenticated source, --repo <vscode-repo-root> for a repository outside the current location, --clone-extensions to copy the source extensions, or --full to disable slim exclusions. For debugging, attach dap-cli to extHostPort, mainPort, or agentHostPort for the extension host, main process, or Agent Host; use cdpPort for the workbench renderer. Give every concurrent launch and Playwright daemon a unique session name, then close the session, terminate Code OSS, and remove the temporary run directory during cleanup.