Skip to main content
VS Code settings control the extension UI and its local CLI process. Environment variables provide machine-level overrides for storage, diagnostics, headless authentication, and hardware tool discovery.

​
VS Code settings

Open VS Code Settings and search for Embedder, or edit settings.json. For example:
Changes to embedder.showSerial and embedder.showReasoningSummaries apply while the extension is running. The two activation settings affect only the first activation behavior for a workspace. The extension resolves embedder.logLevel and initializes error reporting when its extension host starts. Reload the VS Code window after changing embedder.logLevel or embedder.telemetry if you need the new value to apply to the current process.

​
Environment variables

Set environment variables before starting Embedder. In VS Code, the extension host and the CLI process must inherit them, so reload the window after changing the environment.

​
Storage and diagnostics

EMBEDDER_LOG_LEVEL and LOG_LEVEL control different processes. Use both when support asks for trace output from the extension and CLI:

​
Headless and daemon selection

EMBEDDER_TEAM and EMBEDDER_PROJECT must be supplied together. Interactive editor sign-in normally uses stored credentials instead of EMBEDDER_API_KEY.

​
Hardware tool overrides

Prefer EMBEDDER.md for project-specific commands and artifact paths. Use an environment override for a machine-specific installation or discovery problem.

​
Application data paths

The default application-data directory is:
This directory can contain stored credentials, user preferences, telemetry preference, global approval rules, managed tools, and virtual project data. Common files include:
EMBEDDER_APP_DIR relocates these files. On Windows, the managed CLI binary directory defaults to %LOCALAPPDATA%\embedder when you have not set EMBEDDER_APP_DIR. Project-local data uses .embedder/ under the project root. Plans, hardware scripts, captures, traces, schematics, reports, and project configuration can live there. If Embedder cannot write the project directory, writable runtime data falls back to a hashed project directory under the application-data directory.

​
Telemetry controls

Embedder uses telemetry for usage diagnostics, performance reports, error events, and breadcrumbs. Error reporting is configured without default personally identifiable information. You have three control layers:
  1. EMBEDDER_NO_TELEMETRY=1 is the hard machine-process override.
  2. /telemetry on or /telemetry off writes the machine preference to telemetry.json.
  3. embedder.telemetry: false opts the VS Code extension host out.
The VS Code setting is an extension-host opt-out. The slash command controls the stored machine preference read by the CLI and extension. To ensure every Embedder process is off, set EMBEDDER_NO_TELEMETRY=1. Run /telemetry without an argument to inspect the effective state:
When the environment variable is set, /telemetry on is rejected because the setting is pinned off. Restart Embedder after changing telemetry so crash reporting also picks up the new value.
Turning telemetry off does not disable local logs.

​
Log locations

The extension and CLI write separate timestamped files in the same platform log directory: Extension files start with vscode-. CLI files start with log-. Each active file rotates at 10 MB, and old logs are pruned by age and count. Use these surfaces to open diagnostics:
  • /logs opens the CLI log directory;
  • Embedder: Open CLI Logs lets you choose the current extension log, either log directory, or the Embedder output channel;
  • Embedder: Show CLI Process Output opens raw CLI process output.
For a support capture, set the needed log level to trace, reload VS Code, reproduce the problem once, and restore the previous level afterward. Review logs before sharing them because local paths, command output, and environment details can appear in diagnostic records.
Last modified on August 24, 2026