Commands and settings

Everything the extension adds to VS Code. What the underlying flags mean belongs to the CLI, and daybrite.dev/docs/cli documents that.

Commands

All of these are under the Day category in the command palette.

Running

Choosing what runs

Creating and checking

Per-target Run, Stop, Restart and Build, per-project Run and Stop, the + that adds a device to a mobile target, and a device row’s own Play, Stop, Remove Device and Start/Stop Simulator (Emulator on Android) are inline buttons and context-menu entries on their rows rather than palette commands.

Add Target… is also the + on each project’s Targets row, and an entry on that row’s and the project row’s context menus. From a row it adds to that row’s project, whichever project is focused. Targets the project already has are listed with a check mark.

A project row’s context menu starts with Open Day.toml, Reveal in Explorer View and Open Day Extension Settings, which act on that row’s project. Opening Day.toml focuses the project too, as opening any of its files does. When the project is the only folder in the window, the Explorer has no row for that folder, so Reveal in Explorer View selects the project’s Day.toml instead. Open Day Extension Settings shows this extension’s settings where the project’s own values live: the Workspace tab in a window with one folder, and the project’s folder tab in a window with several. Open Settings shows the same settings on the User tab. Clicking the row itself focuses the project without opening anything.

Two more commands sit on the targets that carry a native project to open:

Each is scaffolded source that day new wrote and your app owns, so none of them needs a build first. A row offers the entry only when that directory is actually in the project.

Settings

Finding the CLI

Defaults for a run

Per project

These are folder-scoped: put them in one app’s .vscode/settings.json and they apply to that app alone, which is how several apps in one window run with different log levels or environments. The Day view’s Configuration rows write to the focused project’s folder.

Toolchain locations

Exported for every day command the extension runs — builds, launches, device listing, and day doctor — so Doctor reports on the same toolchains your builds will use. That matters most when VS Code was launched from the Dock or Start menu and inherited none of your shell’s environment.

The editor

Task properties

Tasks of type day accept:

Two problem matchers ship with it: $day-rustc for a one-shot build, and $day-rustc-watch for a long-running task that rebuilds.

Every target is available as a task without any configuration on your part — Tasks: Run Task → day. To pin one to ⌘⇧B or a keybinding, write it into .vscode/tasks.json:

{
  "type": "day",
  "command": "launch",
  "target": "macos-appkit",
  "profile": "debug",
  "script": "dayscript/demo.yaml",
  "problemMatcher": ["$day-rustc"]
}

Launch attributes

Debug configurations of type day take target, profile, locale, script, keepAlive and project — the same set as tasks. Omitting target launches whatever is ticked in the Day view.

{
  "type": "day",
  "request": "launch",
  "name": "Day: Run",
  "target": "macos-appkit"
}

On a desktop target, Start Debugging builds the app and hands the binary to a Rust debugger you already have installed, so breakpoints in .rs files are real. Mobile and web targets launch without a debugger attached.

What lives elsewhere

The extension adds no build logic of its own; it runs the CLI and shows you the result. For the underlying behaviour:

• CLI reference — every subcommand and flag
• Platforms — what each target builds and needs
• dayscript — the script format and its steps
• Packaging — day pack, signing and distribution
• Day for agents — the MCP tools