VS Code Extension 1.2.0

B2C DX VS Code Extension v1.2.0

Download the .vsix file below and install via:

code --install-extension b2c-vs-extension-1.2.0.vsix

Or in VS Code: Extensions → ⋯ → Install from VSIX...

---

Changelog

Minor Changes

• #413 3773648 - Migrate job, code, bm users, bm roles, sites, and catalog discovery to SCAPI-first operation with a temporary OCAPI compatibility fallback. auto tries SCAPI when its coordinates and stateless authentication are available, pins the selected backend for multi-request operations, and falls back only on safe capability/auth/request rejections. Site cartridge-path writes, portable BM user search, disabled-user updates, system-job triggers, SDK/CLI/MCP code-version discovery, and VS Code jobs/code/catalog surfaces now participate. Inventory-list enumeration, BM whoami, access-key administration, and raw OCAPI user-search JSON remain temporary OCAPI compatibility operations because the current live SCAPI schemas have no equivalent. Explicit SCAPI mode rejects these operations before contacting OCAPI and identifies B2C Commerce release 26.8 as the current capability baseline. (Thanks @clavery!)

  setup instance create accepts optional SCAPI coordinates for SCAPI-first active-code-version detection. They are not required in auto; missing coordinates select OCAPI, and failed interactive detection reports the reason before allowing manual entry.

  This is a major release because JSON/results can change shape during the migration. job run, job wait, and job search return canonical camelCase fields with either backend, including OCAPI fallback; consumers must update fields such as execution_status to executionStatus. Other commands can retain backend-specific shapes, for which explicitly selecting OCAPI preserves the legacy shape. SDK high-level code helpers accept an explicit scripts backend; dual-backend factories and JobsCompatibilityBackend expose reusable fallback without making implicit backend selection an SDK-wide policy.

  SCAPI currently requires client-credentials or JWT Bearer authentication. Browser-based user auth continues through OCAPI/WebDAV and is selected by auto; explicit SCAPI with user auth errors clearly until the platform adds support.

  GitHub Action v2 adopts CLI 2.x and its camelCase job results. Existing @v1 workflows remain on the maintained CLI 1.x line, preserving the OCAPI behavior and legacy result shapes of operations migrated in CLI 2 until consumers update their Action references to @v2. CLI 1.x commands designed specifically for SCAPI continue to use SCAPI.

  The VS Code extension uses configured tenant IDs consistently in API Browser, keeps partial export discovery warnings in the output log instead of showing notifications, and supports JWT-authenticated OCAPI fallback equivalently to client credentials.

Patch Changes

• #681 6c8bd53 - Add in-editor API Browser setup help for Admin and Shopper connections. Remove misleading Swagger authorization controls and show token failures with guidance instead of leaving authentication pending. (Thanks @clavery!)

• #643 f208d0c - Made VS Code instance selection workspace-specific by default, with explicit actions to set or follow the shared default without unexpectedly changing other tools and workspaces. Opening an instance's configuration now reveals its exact named entry. (Thanks @clavery!)

• #670 407075c - Add embedded Commerce skills through MCP resources and searchable skills_read, with focused configuration, authentication, and workflow guidance and consistent CLI/MCP recommendations. Enable all toolsets by default, streamline debugging and logging, identify tool effects for client approval controls, and support MCP 2026-07-28 alongside earlier clients. Include concise installation, capabilities, configuration, and security documentation. (Thanks @clavery!)

  Update explicit tool selections to use debug_control, debug_inspect, logs_watch, and mrt_logs_watch; remove pwakit_get_guidelines and scapi_custom_api_generate_scaffold. Remove --allow-non-ga-tools from launch commands. Use --toolsets or --tools to customize the catalog and b2c scaffold generate custom-api for local scaffolding.

• Updated dependencies [304f0eb, 6503d81, 6c8bd53, 3751091, 304f0eb, f208d0c, 407075c, 6503d81, 6503d81, 5741d42, 2f92310, 2f92310, c9cf71f, 2924738, 2dbbf72, 2924738, 1b6bdf8, 407075c, 3773648, 3773648, a0214e4, b2b026c, b2b026c, de36e4a, 304f0eb]:

  • @salesforce/b2c-tooling-sdk@2.0.0

Agent Plugins 1.9.0

Agent skills plugin artifacts for b2c-agent-plugins v1.9.0. Download the *-skills.zip files below.

See the Agent Skills & Plugins guide for installation and usage.

Changelog

Minor Changes

• #672 304f0eb - Add b2c-ops runbooks for job health, checkout and failed-order investigation, and incident triage, available as a skills plugin, through CLI installation, and included in the MCP. Add an Operations guide with example requests, recovery checks, and handoffs to administrators, developers, providers, or Salesforce Support. (Thanks @clavery!)

Patch Changes

• 46ab439 - Lead SCAPI checkout guidance with the documented order payment-instrument authorization, placement, and failure lifecycle while retaining single-phase order hook orchestration as an option. (Thanks @clavery!)

• #680 6503d81 - Analyze B2C Commerce sales, merchandising, and technical trends directly through MCP with CIP report discovery and SQL queries. Includes analytics skills, shared configuration and Safety Mode support, and bounded, cancellable queries without a separate CLI installation. (Thanks @clavery!)

  Report discovery includes source tables and sales metric definitions. Sales, payment, and promotion reports return unavailable averages for zero-count groups instead of failing on division by zero.

• #672 304f0eb - Fix SCAPI system-job requests so site archive imports and exports, including Page Designer content exports, use the required configuration format. Preserve OCAPI compatibility retries and clarify content authentication guidance. (Thanks @clavery!)

• #670 407075c - Add embedded Commerce skills through MCP resources and searchable skills_read, with focused configuration, authentication, and workflow guidance and consistent CLI/MCP recommendations. Enable all toolsets by default, streamline debugging and logging, identify tool effects for client approval controls, and support MCP 2026-07-28 alongside earlier clients. Include concise installation, capabilities, configuration, and security documentation. (Thanks @clavery!)

  Update explicit tool selections to use debug_control, debug_inspect, logs_watch, and mrt_logs_watch; remove pwakit_get_guidelines and scapi_custom_api_generate_scaffold. Remove --allow-non-ga-tools from launch commands. Use --toolsets or --tools to customize the catalog and b2c scaffold generate custom-api for local scaffolding.

• #680 6503d81 - Add reusable workflows for job history, execution steps, code versions, and site cartridge paths. Update MCP task guidance and operational runbooks to use these workflows and exact job-log reads with less reliance on the CLI. (Thanks @clavery!)

• #662 2f92310 - Add a --mrt-backend flag (auto | legacy | scapi, default auto; also MRT_BACKEND env var or mrtBackend in dw.json) to b2c mrt commands. It lets mrt bundle history and mrt bundle deploy <bundleId> run over the SCAPI Storefront Deployments API (OAuth, scopes sfcc.storefront.deployments[.rw]) instead of the legacy MRT Cloud API (per-user API key). auto prefers SCAPI when --short-code/--tenant-id and client-credentials or JWT Bearer auth are configured, otherwise uses legacy, and falls back to legacy on safe pre-execution errors (surfacing the SCAPI error instead when no legacy credentials are configured, so the real failure isn't masked); scapi never silently falls back. All other MRT commands — and mrt bundle deploy's local-build push path — remain on the legacy backend. (Thanks @kieran-sf!)

  Under --json, these commands return the serving backend's native response verbatim (legacy {count, next, previous, deployments} vs SCAPI {limit, offset, total, data}) — the human-readable table is normalized across backends, but --json is not, so pin legacy or scapi when a script needs a stable shape. Legacy-only flags (--api-key, --cloud-origin, --credentials-file) now print a warning under --mrt-backend scapi (where the legacy backend that honors them never runs). --project also gains a --storefront / -s alias for the SCAPI storefront ID.

• #646 c9cf71f - Add b2c mrt bundle upload-v2 for building and uploading v2-format Managed Runtime bundles. The v2 archive is a gzip tar whose files live under a configurable root directory (default bld/) with the SSR configuration written inside the archive at {root-dir}/{config-path} (default bld/.mrt/config.json), uploaded as multipart/form-data. This command is upload-only — deploy the returned bundle ID with b2c mrt bundle deploy <bundleId> -e <env>. Every server-side parameter (root dir, config path, match mode, SSR patterns/parameters, dependencies, and CC overrides) is exposed as a flag. The SDK adds matching createBundleV2, pushBundleV2, and uploadBundleV2 operations. (Thanks @kieran-sf!)

  Bundle commands now read SSR configuration (ssrOnly/ssrShared/ssrParameters) from config.server.ts in the project directory, loaded straight from source, so it no longer needs to be compiled into the build output. Use --project-directory to point at a project other than the current directory (a compiled config.server.js/config.server.mjs and the legacy build/config.server.js are still accepted). For upload-v2, an on-disk v2 config file ({build-dir}/{config-path}) still takes precedence when present; command flags override the resolved values per key. The SDK's createBundle/createBundleV2 gain a projectDirectory option for this.

  Bundles now include the project's declared dependencies as bundle metadata (v1 bundle_metadata.dependencies; v2 bundleMetadata.dependencies inside the archive config), derived from the project package.json (dependencies + devDependencies) — matching pwa-kit/storefront-next. Explicitly provided dependencies (v2 --dependencies) or dependencies already present in the v2 config file take precedence; collection is best-effort and never blocks a bundle if package.json is missing or unreadable.

• #676 2924738 - De-conflict short flags on the mrt command surface so each -x means one thing: (Thanks @kieran-sf!)

  • --cloud-origin moved from -o to -u, freeing -o for --organization (mrt project create / list) and --output (mrt bundle download) — which previously shadowed the base flag. Breaking: update any scripts passing -o for the cloud origin; the long form --cloud-origin is unchanged.
  • mrt project notification create / update: --target (the notification's target-environment list) now also accepts --environment / -e as aliases, since a notification target is an environment. These two commands no longer expose the standalone single-value --environment flag — it was unused there and its --target alias collided with the command's own --target.

• #662 2f92310 - Document SFCC_MRT_BACKEND as a supported way to select the b2c mrt backend (alongside MRT_BACKEND) in the b2c-mrt skill. (Thanks @kieran-sf!)

• #676 2924738 - Add storefront as an alias for project across the mrt command surface, matching the terminology of the SCAPI MRT API. b2c mrt storefront <cmd> now works identically to b2c mrt project <cmd> (including the member and notification subtopics), and --storefront / -s are accepted anywhere --project / -p is. The new MRT_STOREFRONT / SFCC_MRT_STOREFRONT environment variables act as fallbacks for MRT_PROJECT / SFCC_MRT_PROJECT. The project / --project (-p) forms and the existing MRT_PROJECT vari...

Version Packages — b2c-dx-mcp 3.0.1

@salesforce/b2c-dx-mcp@3.0.1

Patch Changes

• #684 d3da83c - Restore --allow-non-ga-tools as a deprecated no-op so existing MCP configurations continue to start after upgrading. The server logs a warning that the flag can be removed; tool availability is unchanged. (Thanks @clavery!)

Version Packages — b2c-cli 2.0.0,b2c-tooling-sdk 2.0.0,b2c-dx-mcp 3.0.0,b2c-vs-extension 1.2.0,docs 0.4.0

@salesforce/b2c-cli@2.0.0

Major Changes

• #676 2924738 - De-conflict short flags on the mrt command surface so each -x means one thing: (Thanks @kieran-sf!)

  • --cloud-origin moved from -o to -u, freeing -o for --organization (mrt project create / list) and --output (mrt bundle download) — which previously shadowed the base flag. Breaking: update any scripts passing -o for the cloud origin; the long form --cloud-origin is unchanged.
  • mrt project notification create / update: --target (the notification's target-environment list) now also accepts --environment / -e as aliases, since a notification target is an environment. These two commands no longer expose the standalone single-value --environment flag — it was unused there and its --target alias collided with the command's own --target.

• #676 2924738 - Add storefront as an alias for project across the mrt command surface, matching the terminology of the SCAPI MRT API. b2c mrt storefront <cmd> now works identically to b2c mrt project <cmd> (including the member and notification subtopics), and --storefront / -s are accepted anywhere --project / -p is. The new MRT_STOREFRONT / SFCC_MRT_STOREFRONT environment variables act as fallbacks for MRT_PROJECT / SFCC_MRT_PROJECT. The project / --project (-p) forms and the existing MRT_PROJECT variables continue to work unchanged. (Thanks @kieran-sf!)

  -s now uniformly means --project / --storefront on every mrt command. To make that consistent, two commands changed their own short flags (breaking):

  • mrt project create no longer has a --slug flag. Set the new project's slug with --project / --storefront (-p / -s) instead — e.g. b2c mrt project create "My Storefront" -o my-org -s my-storefront. When omitted, MRT auto-generates the slug from the name (unchanged). Update any scripts using --slug.
  • mrt bundle save moved --save-dir from -s to -d, freeing -s for the storefront alias. Update any scripts using -s for the save directory (the long form --save-dir is unchanged).

  mrt project get, update, and delete accept the project slug either as a positional argument or via --project / --storefront (-p / -s; also honoring MRT_PROJECT and dw.json). Symmetrically, mrt env create and mrt env delete now accept the environment slug either as a positional argument or via --environment / -e (also honoring MRT_ENVIRONMENT and dw.json). An explicit positional still wins when both are given.

  Error messages surface the alias too: the "MRT project is required" errors now mention --project / --storefront (-p / -s), and passing a flag twice through an alias (e.g. -p x -s y) now reports which long and short forms refer to the same flag instead of the bare "can only be specified once".

  On the mrt project notification commands, --environment (-e) is now the primary flag for specifying environments (previously --target), matching the rest of the mrt surface. --target / -t are retained as aliases so existing scripts keep working, and command output and --help now say "environment" / "Environments" rather than "target". notification list follows suit with an --environment filter and an Environments column.

• #413 3773648 - Migrate job, code, bm users, bm roles, sites, and catalog discovery to SCAPI-first operation with a temporary OCAPI compatibility fallback. auto tries SCAPI when its coordinates and stateless authentication are available, pins the selected backend for multi-request operations, and falls back only on safe capability/auth/request rejections. Site cartridge-path writes, portable BM user search, disabled-user updates, system-job triggers, SDK/CLI/MCP code-version discovery, and VS Code jobs/code/catalog surfaces now participate. Inventory-list enumeration, BM whoami, access-key administration, and raw OCAPI user-search JSON remain temporary OCAPI compatibility operations because the current live SCAPI schemas have no equivalent. Explicit SCAPI mode rejects these operations before contacting OCAPI and identifies B2C Commerce release 26.8 as the current capability baseline. (Thanks @clavery!)

  setup instance create accepts optional SCAPI coordinates for SCAPI-first active-code-version detection. They are not required in auto; missing coordinates select OCAPI, and failed interactive detection reports the reason before allowing manual entry.

  This is a major release because JSON/results can change shape during the migration. job run, job wait, and job search return canonical camelCase fields with either backend, including OCAPI fallback; consumers must update fields such as execution_status to executionStatus. Other commands can retain backend-specific shapes, for which explicitly selecting OCAPI preserves the legacy shape. SDK high-level code helpers accept an explicit scripts backend; dual-backend factories and JobsCompatibilityBackend expose reusable fallback without making implicit backend selection an SDK-wide policy.

  SCAPI currently requires client-credentials or JWT Bearer authentication. Browser-based user auth continues through OCAPI/WebDAV and is selected by auto; explicit SCAPI with user auth errors clearly until the platform adds support.

  GitHub Action v2 adopts CLI 2.x and its camelCase job results. Existing @v1 workflows remain on the maintained CLI 1.x line, preserving the OCAPI behavior and legacy result shapes of operations migrated in CLI 2 until consumers update their Action references to @v2. CLI 1.x commands designed specifically for SCAPI continue to use SCAPI.

  The VS Code extension uses configured tenant IDs consistently in API Browser, keeps partial export discovery warnings in the output log instead of showing notifications, and supports JWT-authenticated OCAPI fallback equivalently to client credentials.

Minor Changes

• #672 304f0eb - Add b2c-ops runbooks for job health, checkout and failed-order investigation, and incident triage, available as a skills plugin, through CLI installation, and included in the MCP. Add an Operations guide with example requests, recovery checks, and handoffs to administrators, developers, providers, or Salesforce Support. (Thanks @clavery!)

• #413 3773648 - Add b2c bm users create to create a Business Manager user (create-or-replace), rounding out the bm users lifecycle alongside list/get/search/update/delete. Runs over SCAPI with OCAPI fallback like the other bm users commands. Flags: --email (required), --first-name, --last-name, --external-id, --password, --role (repeatable), --disabled, and preferred locales. Note that most instances use SSO with Account Manager and reject creating local BM users with LocalUserCreationException — creation succeeds only when the instance is configured to allow local users. (Thanks @clavery!)

• #662 2f92310 - Add a --mrt-backend flag (auto | legacy | scapi, default auto; also MRT_BACKEND env var or mrtBackend in dw.json) to b2c mrt commands. It lets mrt bundle history and mrt bundle deploy <bundleId> run over the SCAPI Storefront Deployments API (OAuth, scopes sfcc.storefront.deployments[.rw]) instead of the legacy MRT Cloud API (per-user API key). auto prefers SCAPI when --short-code/--tenant-id and client-credentials or JWT Bearer auth are configured, otherwise uses legacy, and falls back to legacy on safe pre-execution errors (surfacing the SCAPI error instead when no legacy credentials are configured, so the real failure isn't masked); scapi never silently falls back. All other MRT commands — and mrt bundle deploy's local-build push path — remain on the legacy backend. (Thanks @kieran-sf!)

  Under --json, these commands return the serving backend's native response verbatim (legacy {count, next, previous, deployments} vs SCAPI {limit, offset, total, data}) — the human-readable table is normalized across backends, but --json is not, so pin legacy or scapi when a script needs a stable shape. Legacy-only flags (--api-key, --cloud-origin, --credentials-file) now print a warning under --mrt-backend scapi (where the legacy backend that honors them never runs). --project also gains a --storefront / -s alias for the SCAPI storefront ID.

• #646 [c9cf71f](c9cf71f...

VS Code Extension 1.1.4

B2C DX VS Code Extension v1.1.4

Download the .vsix file below and install via:

code --install-extension b2c-vs-extension-1.1.4.vsix

Or in VS Code: Extensions → ⋯ → Install from VSIX...

---

Changelog

Patch Changes

• Updated dependencies [5d48cfc, 4dee938]:
  • @salesforce/b2c-tooling-sdk@1.24.2

Agent Plugins 1.8.5

Agent skills plugin artifacts for b2c-agent-plugins v1.8.5. Download the *-skills.zip files below.

See the Agent Skills & Plugins guide for installation and usage.

Changelog

Patch Changes

• #638 5d48cfc - Keep debugger server-affinity guidance as a rare PIG-only troubleshooting note instead of prompting users and agents to use dwsid during routine debugging. (Thanks @clavery!)

Version Packages — b2c-cli 1.23.2,b2c-tooling-sdk 1.24.2,b2c-dx-mcp 2.1.2,mrt-utilities 0.3.1,b2c-vs-extension 1.1.4,docs 0.3.23

@salesforce/b2c-cli@1.23.2

Patch Changes

• Updated dependencies [5d48cfc, 4dee938]:
  • @salesforce/b2c-tooling-sdk@1.24.2

@salesforce/b2c-dx-mcp@2.1.2

Patch Changes

• #638 5d48cfc - Keep debugger server-affinity guidance as a rare PIG-only troubleshooting note instead of prompting users and agents to use dwsid during routine debugging. (Thanks @clavery!)

• Updated dependencies [5d48cfc, 4dee938]:

  • @salesforce/b2c-tooling-sdk@1.24.2

@salesforce/b2c-tooling-sdk@1.24.2

Patch Changes

• #638 5d48cfc - Keep debugger server-affinity guidance as a rare PIG-only troubleshooting note instead of prompting users and agents to use dwsid during routine debugging. (Thanks @clavery!)

• #634 4dee938 - Remember when an Account Manager client rejects PKCE so later CLI and VS Code sessions start directly with the compatible implicit flow, and avoid reporting authentication success before the PKCE token exchange completes. (Thanks @clavery!)

@salesforce/mrt-utilities@0.3.1

Patch Changes

• #635 a4a87a9 - Improve streamed response performance by using a runtime-appropriate Brotli quality and periodically flushing compressed output. The Brotli quality and flush threshold can now be tuned via the MRT_BROTLI_COMPRESSION_QUALITY (0-11) and MRT_BROTLI_FLUSH_THRESHOLD_BYTES (bytes) environment variables, and the periodic flushing behavior can be disabled by setting MRT_BROTLI_CHUNKING_ENABLED=false. (Thanks @clavery!)

b2c-vs-extension@1.1.4

Patch Changes

• Updated dependencies [5d48cfc, 4dee938]:
  • @salesforce/b2c-tooling-sdk@1.24.2

Documentation

Patch Changes

• #638 5d48cfc - Keep debugger server-affinity guidance as a rare PIG-only troubleshooting note instead of prompting users and agents to use dwsid during routine debugging. (Thanks @clavery!)

• #634 4dee938 - Remember when an Account Manager client rejects PKCE so later CLI and VS Code sessions start directly with the compatible implicit flow, and avoid reporting authentication success before the PKCE token exchange completes. (Thanks @clavery!)

Agent Skills Plugins

Patch Changes

• #638 5d48cfc - Keep debugger server-affinity guidance as a rare PIG-only troubleshooting note instead of prompting users and agents to use dwsid during routine debugging. (Thanks @clavery!)

VS Code Extension 1.1.3

B2C DX VS Code Extension v1.1.3

Download the .vsix file below and install via:

code --install-extension b2c-vs-extension-1.1.3.vsix

Or in VS Code: Extensions → ⋯ → Install from VSIX...

---

Changelog

Patch Changes

• Updated dependencies [1f25b1e]:
  • @salesforce/b2c-tooling-sdk@1.24.1

VS Code Extension 1.1.2

B2C DX VS Code Extension v1.1.2

Download the .vsix file below and install via:

code --install-extension b2c-vs-extension-1.1.2.vsix

Or in VS Code: Extensions → ⋯ → Install from VSIX...

---

Changelog

Patch Changes

• #627 5f7bff4 - Add a shared global dw.json for the CLI, MCP server, and VS Code extension, managed with b2c setup default-config set|get|unset; primary and global instances are available together without merging their fields. MCP tools now accept per-call projectDirectory and configPath; debugger callers must rename cartridge_directory to cartridgeDirectory and remove client_id. (Thanks @clavery!)

• Updated dependencies [5f7bff4]:

  • @salesforce/b2c-tooling-sdk@1.24.0

Agent Plugins 1.8.4

Agent skills plugin artifacts for b2c-agent-plugins v1.8.4. Download the *-skills.zip files below.

See the Agent Skills & Plugins guide for installation and usage.

Changelog

Patch Changes

• #631 b0b24b8 - Made MCP project resolution provenance consistent and tool guidance more concise, kept local paths out of tool descriptions, and clarified startup documentation workspace detection. Updated MCP protocol libraries and made tool input schemas reject unknown arguments. (Thanks @clavery!)