v0.5.13

Changelog

[0.5.2] — 2026

Changed

• App Watchdog uses a quieter default cadence — The watchdog now pings watched app routes every 90 s by default instead of 30 s, reducing background traffic while still catching apps left frozen on remote breakpoints. The Settings panel now offers 1 minute, 90 seconds (default), 2 minutes, and 5 minutes presets; direct VS Code settings values below 60 s are clamped to 60 s.

[0.5.1] — 2026

Fixed

• App/space lists no longer vanish on slow networks or first org-space selection — Loading the service/app list ran every CF CLI call (cf orgs, cf spaces, cf target, cf apps) under a hard 30 s cap. On the first selection of a fresh org/space, or on a slow network / high-latency CF region, cf apps (and the cf target before it) can legitimately take minutes — the cap killed the process mid-fetch with SIGTERM, so the list loaded briefly and then disappeared with a generic Failed to load apps … CF CLI command failed. error. These data-loading commands now use a 10-minute timeout (verified worst case while still guaranteeing the call eventually errors instead of hanging forever). Quick operational commands (cf logout, cf ssh-enabled, cf scale, app-route lookups) keep their fast 30 s cap; cf restart keeps its own 120 s limit.

[0.5.0] — 2026

Added

• App Watchdog — detects CF apps left frozen on a breakpoint — A debug session that ends without proper cleanup (crashed VS Code window, dropped tunnel, missed breakpoint clear) can leave breakpoints armed inside the remote app; the next request that hits them pauses the whole app for every tester. CDS Debug now:
  • records every app started through Start Debug Sessions (timestamp, region, org, space, mapped route, owner window pid) in ~/.cds-debug/watched-apps.json — shared across VS Code windows and surviving restarts, so monitoring resumes even after the window that started the session crashed;
  • pings each watched app's mapped route on an interval (default 30 s, cdsDebug.appWatchdog.pingIntervalSeconds, also on the Settings panel). Liveness is "did the event loop answer at all": any HTTP status from the app counts as alive, while a client-side timeout or a gateway 502/503/504 counts as not responding — the exact signature of a Node process parked on a breakpoint;
  • flags an app only after 2 consecutive failures (network blips don't alarm), shows a status bar warning (N apps are not responding), and clicking it opens an App Watchdog page with per-app status, route, failure reason, watch window, and Stop watching / Check now actions (CDS Debug: Show App Watchdog);
  • skips apps you are actively debugging — while this window has a live debug session for an app, pausing on your own breakpoint is expected, so checks and failure counting are suspended and resume right after the session ends. Entries owned by another still-alive VS Code window are left to that window; a dead owner is taken over by any window;
  • watches each app for 8 hours from its last debug start (cdsDebug.appWatchdog.watchDurationHours, VS Code settings only), then removes it automatically. The whole feature can be disabled with cdsDebug.appWatchdog.enabled.

[0.4.32] — 2026

Fixed

• The Debug Launcher no longer shows an empty panel after selecting org/space/folder — When cf-sync had synced the org/space structure but not yet the space's apps (or stored spaces in the legacy string format), the launcher served the empty topology list as-is: a READY screen with zero app rows and no live fetch — reported by users as "the Debug Launcher is completely blank". An empty topology app list is now treated as no data on both the webview and extension side, falling through to the cached/live cf apps fetch.
• Webview render failures are visible and recoverable instead of a blank/frozen panel — A renderer exception used to leave the panel blank (on first render) or frozen on a stale screen, with no diagnostics. The launcher now has a render error boundary that shows a recovery screen with a "Reload Launcher" button, reports the error (with stack) to the CDS Debug output channel via a new WEBVIEW_ERROR message, forwards window.onerror/unhandledrejection the same way, and ships static fallback content inside the panel so even a script that never runs is not a silent blank page. An unknown screen state now renders the recovery screen instead of an empty string.
• Loading screens can no longer hang forever when the extension config is missing — LOAD_SPACES/LOAD_APPS/START_DEBUG used to return silently when the saved configuration was absent (e.g. after Reset Configuration while the webview retained old state), stranding the user on a spinner. They now post an explicit error back to the panel.
• Stopping from VS Code's debug toolbar (red square) now also clears remote breakpoints — Only the panel's Stop button ran the defensive setBreakpoints([]) pass; the toolbar stop skipped it, leaving the remote Node inspector holding breakpoints until cf restart. The clear now also runs on externally-terminated sessions, through the child sessions that briefly outlive the root (best-effort, time-bounded), and removes the now-dead Package-browser breakpoints from VS Code state when no session survives.
• Breakpoint-clear timeouts sized for slow CF regions — the per-request/total/loadedSources budgets (0.5 s/2 s/1.5 s) could expire on high-latency regions (ap10, jp10), silently resurrecting the "breakpoint survives until cf restart" bug there. Raised to 1.5 s/4 s/3 s; they only bite when the tunnel is half-open.
• Foreign Debug:-named sessions are left alone — a user-defined launch configuration named Debug: <x> no longer triggers CDS Debug's exited-session cleanup on terminate (notifications, status broadcasts, or the opt-in cf restart of an app the extension does not own).

[0.4.31] — 2026

Fixed

• Package Browser loads reliably on slow / high-latency CF regions — Clicking Package after starting a debug session could intermittently fail to load any packages (or time out after ~60 s) on slow orgs such as ca10, because the warm-up depended on polling the loadedSources request at exactly the right moment while the child "Remote Process" session appeared. This is now addressed on three fronts:
  • Push-based source collection — CDS Debug now records the DAP loadedSource events that vscode-js-debug emits for every (including child) session, accumulating package sources continuously instead of relying solely on polling. Sources that arrive between polls — or before the browser is opened — are no longer missed.
  • A single slow loadedSources request no longer aborts the whole warm-up — a per-request timeout is treated as "not ready yet" and retried, instead of failing the entire load. One laggy request on a slow inspector tunnel used to kill the attempt outright.
  • Deadline instead of a fixed attempt count — the warm-up now waits up to a total budget (180 s) for the child session to appear, rather than a hard 60-attempt ceiling, and wakes immediately when a new session starts or a source event arrives.
• More reliable inspector readiness probe — the pre-attach probe now waits for a non-empty /json/list (a real debuggable target) instead of /json/version (inspector metadata only), so vscode-js-debug finds a target immediately and the child session appears dependably.

[0.4.23-pre.1] — 2026

Fixed

• Package Browser (debug:) breakpoints now turn verified (red) once bound — Breakpoints set in node_modules/package sources opened from the Package Browser as debug: URIs (when the .ts is not on disk) were bound and paused execution, but VS Code's gutter stayed gray because the bind happened via customRequest, which the gutter ignores. The breakpoint mirror now nudges VS Code to re-issue its own setBreakpoints by re-adding the breakpoint once per verifying session (keyed by session + path + line, so no repeated flicker), flipping the dot to red. This complements the file: re-verify fix from 0.4.22.

[0.4.23-pre.0] — 2026

Fixed

• The Package Browser returns to the launcher when its debug session ends — Stopping the debugger from VS Code (or the remote server detaching/crashing/reconnecting) while the Package Browser was open used to leave an empty Packages screen with no sources. CDS Debug now detects that the browsed app is no longer attached and navigates back to the app-selection (launcher) screen automatically.

[0.4.23] — 2026

Stable release consolidating the 0.4.7-pre.x line (changes since 0.4.4).

Highlights

• No-install package debugging — the Package Browser opens dependency sources from the running app and no longer writes files into node_modules.
• Reliable package breakpoints — breakpoints in node_modules/package sources show as verified (red) once their script loads; stopping a session clears remote breakpoints so the app no longer stays paused in the Node inspector (no cf restart).
• CF instance counts & safe scaling from the panel, and auto-retrying background topology sync after a failed or canceled run.

[0.4.7-pre.14] — 2026

Fixed

• node_modules breakpoints now show as verified (red) instead of staying gray after the script loads — When a CAP handler in node_modules loads lazily, BreakpointResolver already re-bound the breakpoint via a customRequest (working around vscode-js-debug#1510) so execution paused — but a customRequest does not update VS Code's gutter, so the dot stayed gray. It now also removes and re-adds the matching file: breakpoint once per session (deduped by session + path + line, so no repeated flicker), forcing VS Code to re-issue its own setBreakpoints against the now-loaded script and flip the dot to red. debug: URIs ...

v0.5.12

Changelog

[0.5.2] — 2026

Changed

• App Watchdog uses a quieter default cadence — The watchdog now pings watched app routes every 90 s by default instead of 30 s, reducing background traffic while still catching apps left frozen on remote breakpoints. The Settings panel now offers 1 minute, 90 seconds (default), 2 minutes, and 5 minutes presets; direct VS Code settings values below 60 s are clamped to 60 s.

[0.5.1] — 2026

Fixed

• App/space lists no longer vanish on slow networks or first org-space selection — Loading the service/app list ran every CF CLI call (cf orgs, cf spaces, cf target, cf apps) under a hard 30 s cap. On the first selection of a fresh org/space, or on a slow network / high-latency CF region, cf apps (and the cf target before it) can legitimately take minutes — the cap killed the process mid-fetch with SIGTERM, so the list loaded briefly and then disappeared with a generic Failed to load apps … CF CLI command failed. error. These data-loading commands now use a 10-minute timeout (verified worst case while still guaranteeing the call eventually errors instead of hanging forever). Quick operational commands (cf logout, cf ssh-enabled, cf scale, app-route lookups) keep their fast 30 s cap; cf restart keeps its own 120 s limit.

[0.5.0] — 2026

Added

• App Watchdog — detects CF apps left frozen on a breakpoint — A debug session that ends without proper cleanup (crashed VS Code window, dropped tunnel, missed breakpoint clear) can leave breakpoints armed inside the remote app; the next request that hits them pauses the whole app for every tester. CDS Debug now:
  • records every app started through Start Debug Sessions (timestamp, region, org, space, mapped route, owner window pid) in ~/.cds-debug/watched-apps.json — shared across VS Code windows and surviving restarts, so monitoring resumes even after the window that started the session crashed;
  • pings each watched app's mapped route on an interval (default 30 s, cdsDebug.appWatchdog.pingIntervalSeconds, also on the Settings panel). Liveness is "did the event loop answer at all": any HTTP status from the app counts as alive, while a client-side timeout or a gateway 502/503/504 counts as not responding — the exact signature of a Node process parked on a breakpoint;
  • flags an app only after 2 consecutive failures (network blips don't alarm), shows a status bar warning (N apps are not responding), and clicking it opens an App Watchdog page with per-app status, route, failure reason, watch window, and Stop watching / Check now actions (CDS Debug: Show App Watchdog);
  • skips apps you are actively debugging — while this window has a live debug session for an app, pausing on your own breakpoint is expected, so checks and failure counting are suspended and resume right after the session ends. Entries owned by another still-alive VS Code window are left to that window; a dead owner is taken over by any window;
  • watches each app for 8 hours from its last debug start (cdsDebug.appWatchdog.watchDurationHours, VS Code settings only), then removes it automatically. The whole feature can be disabled with cdsDebug.appWatchdog.enabled.

[0.4.32] — 2026

Fixed

• The Debug Launcher no longer shows an empty panel after selecting org/space/folder — When cf-sync had synced the org/space structure but not yet the space's apps (or stored spaces in the legacy string format), the launcher served the empty topology list as-is: a READY screen with zero app rows and no live fetch — reported by users as "the Debug Launcher is completely blank". An empty topology app list is now treated as no data on both the webview and extension side, falling through to the cached/live cf apps fetch.
• Webview render failures are visible and recoverable instead of a blank/frozen panel — A renderer exception used to leave the panel blank (on first render) or frozen on a stale screen, with no diagnostics. The launcher now has a render error boundary that shows a recovery screen with a "Reload Launcher" button, reports the error (with stack) to the CDS Debug output channel via a new WEBVIEW_ERROR message, forwards window.onerror/unhandledrejection the same way, and ships static fallback content inside the panel so even a script that never runs is not a silent blank page. An unknown screen state now renders the recovery screen instead of an empty string.
• Loading screens can no longer hang forever when the extension config is missing — LOAD_SPACES/LOAD_APPS/START_DEBUG used to return silently when the saved configuration was absent (e.g. after Reset Configuration while the webview retained old state), stranding the user on a spinner. They now post an explicit error back to the panel.
• Stopping from VS Code's debug toolbar (red square) now also clears remote breakpoints — Only the panel's Stop button ran the defensive setBreakpoints([]) pass; the toolbar stop skipped it, leaving the remote Node inspector holding breakpoints until cf restart. The clear now also runs on externally-terminated sessions, through the child sessions that briefly outlive the root (best-effort, time-bounded), and removes the now-dead Package-browser breakpoints from VS Code state when no session survives.
• Breakpoint-clear timeouts sized for slow CF regions — the per-request/total/loadedSources budgets (0.5 s/2 s/1.5 s) could expire on high-latency regions (ap10, jp10), silently resurrecting the "breakpoint survives until cf restart" bug there. Raised to 1.5 s/4 s/3 s; they only bite when the tunnel is half-open.
• Foreign Debug:-named sessions are left alone — a user-defined launch configuration named Debug: <x> no longer triggers CDS Debug's exited-session cleanup on terminate (notifications, status broadcasts, or the opt-in cf restart of an app the extension does not own).

[0.4.31] — 2026

Fixed

• Package Browser loads reliably on slow / high-latency CF regions — Clicking Package after starting a debug session could intermittently fail to load any packages (or time out after ~60 s) on slow orgs such as ca10, because the warm-up depended on polling the loadedSources request at exactly the right moment while the child "Remote Process" session appeared. This is now addressed on three fronts:
  • Push-based source collection — CDS Debug now records the DAP loadedSource events that vscode-js-debug emits for every (including child) session, accumulating package sources continuously instead of relying solely on polling. Sources that arrive between polls — or before the browser is opened — are no longer missed.
  • A single slow loadedSources request no longer aborts the whole warm-up — a per-request timeout is treated as "not ready yet" and retried, instead of failing the entire load. One laggy request on a slow inspector tunnel used to kill the attempt outright.
  • Deadline instead of a fixed attempt count — the warm-up now waits up to a total budget (180 s) for the child session to appear, rather than a hard 60-attempt ceiling, and wakes immediately when a new session starts or a source event arrives.
• More reliable inspector readiness probe — the pre-attach probe now waits for a non-empty /json/list (a real debuggable target) instead of /json/version (inspector metadata only), so vscode-js-debug finds a target immediately and the child session appears dependably.

[0.4.23-pre.1] — 2026

Fixed

• Package Browser (debug:) breakpoints now turn verified (red) once bound — Breakpoints set in node_modules/package sources opened from the Package Browser as debug: URIs (when the .ts is not on disk) were bound and paused execution, but VS Code's gutter stayed gray because the bind happened via customRequest, which the gutter ignores. The breakpoint mirror now nudges VS Code to re-issue its own setBreakpoints by re-adding the breakpoint once per verifying session (keyed by session + path + line, so no repeated flicker), flipping the dot to red. This complements the file: re-verify fix from 0.4.22.

[0.4.23-pre.0] — 2026

Fixed

• The Package Browser returns to the launcher when its debug session ends — Stopping the debugger from VS Code (or the remote server detaching/crashing/reconnecting) while the Package Browser was open used to leave an empty Packages screen with no sources. CDS Debug now detects that the browsed app is no longer attached and navigates back to the app-selection (launcher) screen automatically.

[0.4.23] — 2026

Stable release consolidating the 0.4.7-pre.x line (changes since 0.4.4).

Highlights

• No-install package debugging — the Package Browser opens dependency sources from the running app and no longer writes files into node_modules.
• Reliable package breakpoints — breakpoints in node_modules/package sources show as verified (red) once their script loads; stopping a session clears remote breakpoints so the app no longer stays paused in the Node inspector (no cf restart).
• CF instance counts & safe scaling from the panel, and auto-retrying background topology sync after a failed or canceled run.

[0.4.7-pre.14] — 2026

Fixed

• node_modules breakpoints now show as verified (red) instead of staying gray after the script loads — When a CAP handler in node_modules loads lazily, BreakpointResolver already re-bound the breakpoint via a customRequest (working around vscode-js-debug#1510) so execution paused — but a customRequest does not update VS Code's gutter, so the dot stayed gray. It now also removes and re-adds the matching file: breakpoint once per session (deduped by session + path + line, so no repeated flicker), forcing VS Code to re-issue its own setBreakpoints against the now-loaded script and flip the dot to red. debug: URIs ...

v0.5.11

Changelog

[0.5.2] — 2026

Changed

• App Watchdog uses a quieter default cadence — The watchdog now pings watched app routes every 90 s by default instead of 30 s, reducing background traffic while still catching apps left frozen on remote breakpoints. The Settings panel now offers 1 minute, 90 seconds (default), 2 minutes, and 5 minutes presets; direct VS Code settings values below 60 s are clamped to 60 s.

[0.5.1] — 2026

Fixed

• App/space lists no longer vanish on slow networks or first org-space selection — Loading the service/app list ran every CF CLI call (cf orgs, cf spaces, cf target, cf apps) under a hard 30 s cap. On the first selection of a fresh org/space, or on a slow network / high-latency CF region, cf apps (and the cf target before it) can legitimately take minutes — the cap killed the process mid-fetch with SIGTERM, so the list loaded briefly and then disappeared with a generic Failed to load apps … CF CLI command failed. error. These data-loading commands now use a 10-minute timeout (verified worst case while still guaranteeing the call eventually errors instead of hanging forever). Quick operational commands (cf logout, cf ssh-enabled, cf scale, app-route lookups) keep their fast 30 s cap; cf restart keeps its own 120 s limit.

[0.5.0] — 2026

Added

• App Watchdog — detects CF apps left frozen on a breakpoint — A debug session that ends without proper cleanup (crashed VS Code window, dropped tunnel, missed breakpoint clear) can leave breakpoints armed inside the remote app; the next request that hits them pauses the whole app for every tester. CDS Debug now:
  • records every app started through Start Debug Sessions (timestamp, region, org, space, mapped route, owner window pid) in ~/.cds-debug/watched-apps.json — shared across VS Code windows and surviving restarts, so monitoring resumes even after the window that started the session crashed;
  • pings each watched app's mapped route on an interval (default 30 s, cdsDebug.appWatchdog.pingIntervalSeconds, also on the Settings panel). Liveness is "did the event loop answer at all": any HTTP status from the app counts as alive, while a client-side timeout or a gateway 502/503/504 counts as not responding — the exact signature of a Node process parked on a breakpoint;
  • flags an app only after 2 consecutive failures (network blips don't alarm), shows a status bar warning (N apps are not responding), and clicking it opens an App Watchdog page with per-app status, route, failure reason, watch window, and Stop watching / Check now actions (CDS Debug: Show App Watchdog);
  • skips apps you are actively debugging — while this window has a live debug session for an app, pausing on your own breakpoint is expected, so checks and failure counting are suspended and resume right after the session ends. Entries owned by another still-alive VS Code window are left to that window; a dead owner is taken over by any window;
  • watches each app for 8 hours from its last debug start (cdsDebug.appWatchdog.watchDurationHours, VS Code settings only), then removes it automatically. The whole feature can be disabled with cdsDebug.appWatchdog.enabled.

[0.4.32] — 2026

Fixed

• The Debug Launcher no longer shows an empty panel after selecting org/space/folder — When cf-sync had synced the org/space structure but not yet the space's apps (or stored spaces in the legacy string format), the launcher served the empty topology list as-is: a READY screen with zero app rows and no live fetch — reported by users as "the Debug Launcher is completely blank". An empty topology app list is now treated as no data on both the webview and extension side, falling through to the cached/live cf apps fetch.
• Webview render failures are visible and recoverable instead of a blank/frozen panel — A renderer exception used to leave the panel blank (on first render) or frozen on a stale screen, with no diagnostics. The launcher now has a render error boundary that shows a recovery screen with a "Reload Launcher" button, reports the error (with stack) to the CDS Debug output channel via a new WEBVIEW_ERROR message, forwards window.onerror/unhandledrejection the same way, and ships static fallback content inside the panel so even a script that never runs is not a silent blank page. An unknown screen state now renders the recovery screen instead of an empty string.
• Loading screens can no longer hang forever when the extension config is missing — LOAD_SPACES/LOAD_APPS/START_DEBUG used to return silently when the saved configuration was absent (e.g. after Reset Configuration while the webview retained old state), stranding the user on a spinner. They now post an explicit error back to the panel.
• Stopping from VS Code's debug toolbar (red square) now also clears remote breakpoints — Only the panel's Stop button ran the defensive setBreakpoints([]) pass; the toolbar stop skipped it, leaving the remote Node inspector holding breakpoints until cf restart. The clear now also runs on externally-terminated sessions, through the child sessions that briefly outlive the root (best-effort, time-bounded), and removes the now-dead Package-browser breakpoints from VS Code state when no session survives.
• Breakpoint-clear timeouts sized for slow CF regions — the per-request/total/loadedSources budgets (0.5 s/2 s/1.5 s) could expire on high-latency regions (ap10, jp10), silently resurrecting the "breakpoint survives until cf restart" bug there. Raised to 1.5 s/4 s/3 s; they only bite when the tunnel is half-open.
• Foreign Debug:-named sessions are left alone — a user-defined launch configuration named Debug: <x> no longer triggers CDS Debug's exited-session cleanup on terminate (notifications, status broadcasts, or the opt-in cf restart of an app the extension does not own).

[0.4.31] — 2026

Fixed

• Package Browser loads reliably on slow / high-latency CF regions — Clicking Package after starting a debug session could intermittently fail to load any packages (or time out after ~60 s) on slow orgs such as ca10, because the warm-up depended on polling the loadedSources request at exactly the right moment while the child "Remote Process" session appeared. This is now addressed on three fronts:
  • Push-based source collection — CDS Debug now records the DAP loadedSource events that vscode-js-debug emits for every (including child) session, accumulating package sources continuously instead of relying solely on polling. Sources that arrive between polls — or before the browser is opened — are no longer missed.
  • A single slow loadedSources request no longer aborts the whole warm-up — a per-request timeout is treated as "not ready yet" and retried, instead of failing the entire load. One laggy request on a slow inspector tunnel used to kill the attempt outright.
  • Deadline instead of a fixed attempt count — the warm-up now waits up to a total budget (180 s) for the child session to appear, rather than a hard 60-attempt ceiling, and wakes immediately when a new session starts or a source event arrives.
• More reliable inspector readiness probe — the pre-attach probe now waits for a non-empty /json/list (a real debuggable target) instead of /json/version (inspector metadata only), so vscode-js-debug finds a target immediately and the child session appears dependably.

[0.4.23-pre.1] — 2026

Fixed

• Package Browser (debug:) breakpoints now turn verified (red) once bound — Breakpoints set in node_modules/package sources opened from the Package Browser as debug: URIs (when the .ts is not on disk) were bound and paused execution, but VS Code's gutter stayed gray because the bind happened via customRequest, which the gutter ignores. The breakpoint mirror now nudges VS Code to re-issue its own setBreakpoints by re-adding the breakpoint once per verifying session (keyed by session + path + line, so no repeated flicker), flipping the dot to red. This complements the file: re-verify fix from 0.4.22.

[0.4.23-pre.0] — 2026

Fixed

• The Package Browser returns to the launcher when its debug session ends — Stopping the debugger from VS Code (or the remote server detaching/crashing/reconnecting) while the Package Browser was open used to leave an empty Packages screen with no sources. CDS Debug now detects that the browsed app is no longer attached and navigates back to the app-selection (launcher) screen automatically.

[0.4.23] — 2026

Stable release consolidating the 0.4.7-pre.x line (changes since 0.4.4).

Highlights

• No-install package debugging — the Package Browser opens dependency sources from the running app and no longer writes files into node_modules.
• Reliable package breakpoints — breakpoints in node_modules/package sources show as verified (red) once their script loads; stopping a session clears remote breakpoints so the app no longer stays paused in the Node inspector (no cf restart).
• CF instance counts & safe scaling from the panel, and auto-retrying background topology sync after a failed or canceled run.

[0.4.7-pre.14] — 2026

Fixed

• node_modules breakpoints now show as verified (red) instead of staying gray after the script loads — When a CAP handler in node_modules loads lazily, BreakpointResolver already re-bound the breakpoint via a customRequest (working around vscode-js-debug#1510) so execution paused — but a customRequest does not update VS Code's gutter, so the dot stayed gray. It now also removes and re-adds the matching file: breakpoint once per session (deduped by session + path + line, so no repeated flicker), forcing VS Code to re-issue its own setBreakpoints against the now-loaded script and flip the dot to red. debug: URIs ...

v0.5.10

Changelog

[0.5.2] — 2026

Changed

• App Watchdog uses a quieter default cadence — The watchdog now pings watched app routes every 90 s by default instead of 30 s, reducing background traffic while still catching apps left frozen on remote breakpoints. The Settings panel now offers 1 minute, 90 seconds (default), 2 minutes, and 5 minutes presets; direct VS Code settings values below 60 s are clamped to 60 s.

[0.5.1] — 2026

Fixed

• App/space lists no longer vanish on slow networks or first org-space selection — Loading the service/app list ran every CF CLI call (cf orgs, cf spaces, cf target, cf apps) under a hard 30 s cap. On the first selection of a fresh org/space, or on a slow network / high-latency CF region, cf apps (and the cf target before it) can legitimately take minutes — the cap killed the process mid-fetch with SIGTERM, so the list loaded briefly and then disappeared with a generic Failed to load apps … CF CLI command failed. error. These data-loading commands now use a 10-minute timeout (verified worst case while still guaranteeing the call eventually errors instead of hanging forever). Quick operational commands (cf logout, cf ssh-enabled, cf scale, app-route lookups) keep their fast 30 s cap; cf restart keeps its own 120 s limit.

[0.5.0] — 2026

Added

• App Watchdog — detects CF apps left frozen on a breakpoint — A debug session that ends without proper cleanup (crashed VS Code window, dropped tunnel, missed breakpoint clear) can leave breakpoints armed inside the remote app; the next request that hits them pauses the whole app for every tester. CDS Debug now:
  • records every app started through Start Debug Sessions (timestamp, region, org, space, mapped route, owner window pid) in ~/.cds-debug/watched-apps.json — shared across VS Code windows and surviving restarts, so monitoring resumes even after the window that started the session crashed;
  • pings each watched app's mapped route on an interval (default 30 s, cdsDebug.appWatchdog.pingIntervalSeconds, also on the Settings panel). Liveness is "did the event loop answer at all": any HTTP status from the app counts as alive, while a client-side timeout or a gateway 502/503/504 counts as not responding — the exact signature of a Node process parked on a breakpoint;
  • flags an app only after 2 consecutive failures (network blips don't alarm), shows a status bar warning (N apps are not responding), and clicking it opens an App Watchdog page with per-app status, route, failure reason, watch window, and Stop watching / Check now actions (CDS Debug: Show App Watchdog);
  • skips apps you are actively debugging — while this window has a live debug session for an app, pausing on your own breakpoint is expected, so checks and failure counting are suspended and resume right after the session ends. Entries owned by another still-alive VS Code window are left to that window; a dead owner is taken over by any window;
  • watches each app for 8 hours from its last debug start (cdsDebug.appWatchdog.watchDurationHours, VS Code settings only), then removes it automatically. The whole feature can be disabled with cdsDebug.appWatchdog.enabled.

[0.4.32] — 2026

Fixed

• The Debug Launcher no longer shows an empty panel after selecting org/space/folder — When cf-sync had synced the org/space structure but not yet the space's apps (or stored spaces in the legacy string format), the launcher served the empty topology list as-is: a READY screen with zero app rows and no live fetch — reported by users as "the Debug Launcher is completely blank". An empty topology app list is now treated as no data on both the webview and extension side, falling through to the cached/live cf apps fetch.
• Webview render failures are visible and recoverable instead of a blank/frozen panel — A renderer exception used to leave the panel blank (on first render) or frozen on a stale screen, with no diagnostics. The launcher now has a render error boundary that shows a recovery screen with a "Reload Launcher" button, reports the error (with stack) to the CDS Debug output channel via a new WEBVIEW_ERROR message, forwards window.onerror/unhandledrejection the same way, and ships static fallback content inside the panel so even a script that never runs is not a silent blank page. An unknown screen state now renders the recovery screen instead of an empty string.
• Loading screens can no longer hang forever when the extension config is missing — LOAD_SPACES/LOAD_APPS/START_DEBUG used to return silently when the saved configuration was absent (e.g. after Reset Configuration while the webview retained old state), stranding the user on a spinner. They now post an explicit error back to the panel.
• Stopping from VS Code's debug toolbar (red square) now also clears remote breakpoints — Only the panel's Stop button ran the defensive setBreakpoints([]) pass; the toolbar stop skipped it, leaving the remote Node inspector holding breakpoints until cf restart. The clear now also runs on externally-terminated sessions, through the child sessions that briefly outlive the root (best-effort, time-bounded), and removes the now-dead Package-browser breakpoints from VS Code state when no session survives.
• Breakpoint-clear timeouts sized for slow CF regions — the per-request/total/loadedSources budgets (0.5 s/2 s/1.5 s) could expire on high-latency regions (ap10, jp10), silently resurrecting the "breakpoint survives until cf restart" bug there. Raised to 1.5 s/4 s/3 s; they only bite when the tunnel is half-open.
• Foreign Debug:-named sessions are left alone — a user-defined launch configuration named Debug: <x> no longer triggers CDS Debug's exited-session cleanup on terminate (notifications, status broadcasts, or the opt-in cf restart of an app the extension does not own).

[0.4.31] — 2026

Fixed

• Package Browser loads reliably on slow / high-latency CF regions — Clicking Package after starting a debug session could intermittently fail to load any packages (or time out after ~60 s) on slow orgs such as ca10, because the warm-up depended on polling the loadedSources request at exactly the right moment while the child "Remote Process" session appeared. This is now addressed on three fronts:
  • Push-based source collection — CDS Debug now records the DAP loadedSource events that vscode-js-debug emits for every (including child) session, accumulating package sources continuously instead of relying solely on polling. Sources that arrive between polls — or before the browser is opened — are no longer missed.
  • A single slow loadedSources request no longer aborts the whole warm-up — a per-request timeout is treated as "not ready yet" and retried, instead of failing the entire load. One laggy request on a slow inspector tunnel used to kill the attempt outright.
  • Deadline instead of a fixed attempt count — the warm-up now waits up to a total budget (180 s) for the child session to appear, rather than a hard 60-attempt ceiling, and wakes immediately when a new session starts or a source event arrives.
• More reliable inspector readiness probe — the pre-attach probe now waits for a non-empty /json/list (a real debuggable target) instead of /json/version (inspector metadata only), so vscode-js-debug finds a target immediately and the child session appears dependably.

[0.4.23-pre.1] — 2026

Fixed

• Package Browser (debug:) breakpoints now turn verified (red) once bound — Breakpoints set in node_modules/package sources opened from the Package Browser as debug: URIs (when the .ts is not on disk) were bound and paused execution, but VS Code's gutter stayed gray because the bind happened via customRequest, which the gutter ignores. The breakpoint mirror now nudges VS Code to re-issue its own setBreakpoints by re-adding the breakpoint once per verifying session (keyed by session + path + line, so no repeated flicker), flipping the dot to red. This complements the file: re-verify fix from 0.4.22.

[0.4.23-pre.0] — 2026

Fixed

• The Package Browser returns to the launcher when its debug session ends — Stopping the debugger from VS Code (or the remote server detaching/crashing/reconnecting) while the Package Browser was open used to leave an empty Packages screen with no sources. CDS Debug now detects that the browsed app is no longer attached and navigates back to the app-selection (launcher) screen automatically.

[0.4.23] — 2026

Stable release consolidating the 0.4.7-pre.x line (changes since 0.4.4).

Highlights

• No-install package debugging — the Package Browser opens dependency sources from the running app and no longer writes files into node_modules.
• Reliable package breakpoints — breakpoints in node_modules/package sources show as verified (red) once their script loads; stopping a session clears remote breakpoints so the app no longer stays paused in the Node inspector (no cf restart).
• CF instance counts & safe scaling from the panel, and auto-retrying background topology sync after a failed or canceled run.

[0.4.7-pre.14] — 2026

Fixed

• node_modules breakpoints now show as verified (red) instead of staying gray after the script loads — When a CAP handler in node_modules loads lazily, BreakpointResolver already re-bound the breakpoint via a customRequest (working around vscode-js-debug#1510) so execution paused — but a customRequest does not update VS Code's gutter, so the dot stayed gray. It now also removes and re-adds the matching file: breakpoint once per session (deduped by session + path + line, so no repeated flicker), forcing VS Code to re-issue its own setBreakpoints against the now-loaded script and flip the dot to red. debug: URIs ...

v0.5.9

Changelog

[0.5.2] — 2026

Changed

• App Watchdog uses a quieter default cadence — The watchdog now pings watched app routes every 90 s by default instead of 30 s, reducing background traffic while still catching apps left frozen on remote breakpoints. The Settings panel now offers 1 minute, 90 seconds (default), 2 minutes, and 5 minutes presets; direct VS Code settings values below 60 s are clamped to 60 s.

[0.5.1] — 2026

Fixed

• App/space lists no longer vanish on slow networks or first org-space selection — Loading the service/app list ran every CF CLI call (cf orgs, cf spaces, cf target, cf apps) under a hard 30 s cap. On the first selection of a fresh org/space, or on a slow network / high-latency CF region, cf apps (and the cf target before it) can legitimately take minutes — the cap killed the process mid-fetch with SIGTERM, so the list loaded briefly and then disappeared with a generic Failed to load apps … CF CLI command failed. error. These data-loading commands now use a 10-minute timeout (verified worst case while still guaranteeing the call eventually errors instead of hanging forever). Quick operational commands (cf logout, cf ssh-enabled, cf scale, app-route lookups) keep their fast 30 s cap; cf restart keeps its own 120 s limit.

[0.5.0] — 2026

Added

• App Watchdog — detects CF apps left frozen on a breakpoint — A debug session that ends without proper cleanup (crashed VS Code window, dropped tunnel, missed breakpoint clear) can leave breakpoints armed inside the remote app; the next request that hits them pauses the whole app for every tester. CDS Debug now:
  • records every app started through Start Debug Sessions (timestamp, region, org, space, mapped route, owner window pid) in ~/.cds-debug/watched-apps.json — shared across VS Code windows and surviving restarts, so monitoring resumes even after the window that started the session crashed;
  • pings each watched app's mapped route on an interval (default 30 s, cdsDebug.appWatchdog.pingIntervalSeconds, also on the Settings panel). Liveness is "did the event loop answer at all": any HTTP status from the app counts as alive, while a client-side timeout or a gateway 502/503/504 counts as not responding — the exact signature of a Node process parked on a breakpoint;
  • flags an app only after 2 consecutive failures (network blips don't alarm), shows a status bar warning (N apps are not responding), and clicking it opens an App Watchdog page with per-app status, route, failure reason, watch window, and Stop watching / Check now actions (CDS Debug: Show App Watchdog);
  • skips apps you are actively debugging — while this window has a live debug session for an app, pausing on your own breakpoint is expected, so checks and failure counting are suspended and resume right after the session ends. Entries owned by another still-alive VS Code window are left to that window; a dead owner is taken over by any window;
  • watches each app for 8 hours from its last debug start (cdsDebug.appWatchdog.watchDurationHours, VS Code settings only), then removes it automatically. The whole feature can be disabled with cdsDebug.appWatchdog.enabled.

[0.4.32] — 2026

Fixed

• The Debug Launcher no longer shows an empty panel after selecting org/space/folder — When cf-sync had synced the org/space structure but not yet the space's apps (or stored spaces in the legacy string format), the launcher served the empty topology list as-is: a READY screen with zero app rows and no live fetch — reported by users as "the Debug Launcher is completely blank". An empty topology app list is now treated as no data on both the webview and extension side, falling through to the cached/live cf apps fetch.
• Webview render failures are visible and recoverable instead of a blank/frozen panel — A renderer exception used to leave the panel blank (on first render) or frozen on a stale screen, with no diagnostics. The launcher now has a render error boundary that shows a recovery screen with a "Reload Launcher" button, reports the error (with stack) to the CDS Debug output channel via a new WEBVIEW_ERROR message, forwards window.onerror/unhandledrejection the same way, and ships static fallback content inside the panel so even a script that never runs is not a silent blank page. An unknown screen state now renders the recovery screen instead of an empty string.
• Loading screens can no longer hang forever when the extension config is missing — LOAD_SPACES/LOAD_APPS/START_DEBUG used to return silently when the saved configuration was absent (e.g. after Reset Configuration while the webview retained old state), stranding the user on a spinner. They now post an explicit error back to the panel.
• Stopping from VS Code's debug toolbar (red square) now also clears remote breakpoints — Only the panel's Stop button ran the defensive setBreakpoints([]) pass; the toolbar stop skipped it, leaving the remote Node inspector holding breakpoints until cf restart. The clear now also runs on externally-terminated sessions, through the child sessions that briefly outlive the root (best-effort, time-bounded), and removes the now-dead Package-browser breakpoints from VS Code state when no session survives.
• Breakpoint-clear timeouts sized for slow CF regions — the per-request/total/loadedSources budgets (0.5 s/2 s/1.5 s) could expire on high-latency regions (ap10, jp10), silently resurrecting the "breakpoint survives until cf restart" bug there. Raised to 1.5 s/4 s/3 s; they only bite when the tunnel is half-open.
• Foreign Debug:-named sessions are left alone — a user-defined launch configuration named Debug: <x> no longer triggers CDS Debug's exited-session cleanup on terminate (notifications, status broadcasts, or the opt-in cf restart of an app the extension does not own).

[0.4.31] — 2026

Fixed

• Package Browser loads reliably on slow / high-latency CF regions — Clicking Package after starting a debug session could intermittently fail to load any packages (or time out after ~60 s) on slow orgs such as ca10, because the warm-up depended on polling the loadedSources request at exactly the right moment while the child "Remote Process" session appeared. This is now addressed on three fronts:
  • Push-based source collection — CDS Debug now records the DAP loadedSource events that vscode-js-debug emits for every (including child) session, accumulating package sources continuously instead of relying solely on polling. Sources that arrive between polls — or before the browser is opened — are no longer missed.
  • A single slow loadedSources request no longer aborts the whole warm-up — a per-request timeout is treated as "not ready yet" and retried, instead of failing the entire load. One laggy request on a slow inspector tunnel used to kill the attempt outright.
  • Deadline instead of a fixed attempt count — the warm-up now waits up to a total budget (180 s) for the child session to appear, rather than a hard 60-attempt ceiling, and wakes immediately when a new session starts or a source event arrives.
• More reliable inspector readiness probe — the pre-attach probe now waits for a non-empty /json/list (a real debuggable target) instead of /json/version (inspector metadata only), so vscode-js-debug finds a target immediately and the child session appears dependably.

[0.4.23-pre.1] — 2026

Fixed

• Package Browser (debug:) breakpoints now turn verified (red) once bound — Breakpoints set in node_modules/package sources opened from the Package Browser as debug: URIs (when the .ts is not on disk) were bound and paused execution, but VS Code's gutter stayed gray because the bind happened via customRequest, which the gutter ignores. The breakpoint mirror now nudges VS Code to re-issue its own setBreakpoints by re-adding the breakpoint once per verifying session (keyed by session + path + line, so no repeated flicker), flipping the dot to red. This complements the file: re-verify fix from 0.4.22.

[0.4.23-pre.0] — 2026

Fixed

• The Package Browser returns to the launcher when its debug session ends — Stopping the debugger from VS Code (or the remote server detaching/crashing/reconnecting) while the Package Browser was open used to leave an empty Packages screen with no sources. CDS Debug now detects that the browsed app is no longer attached and navigates back to the app-selection (launcher) screen automatically.

[0.4.23] — 2026

Stable release consolidating the 0.4.7-pre.x line (changes since 0.4.4).

Highlights

• No-install package debugging — the Package Browser opens dependency sources from the running app and no longer writes files into node_modules.
• Reliable package breakpoints — breakpoints in node_modules/package sources show as verified (red) once their script loads; stopping a session clears remote breakpoints so the app no longer stays paused in the Node inspector (no cf restart).
• CF instance counts & safe scaling from the panel, and auto-retrying background topology sync after a failed or canceled run.

[0.4.7-pre.14] — 2026

Fixed

• node_modules breakpoints now show as verified (red) instead of staying gray after the script loads — When a CAP handler in node_modules loads lazily, BreakpointResolver already re-bound the breakpoint via a customRequest (working around vscode-js-debug#1510) so execution paused — but a customRequest does not update VS Code's gutter, so the dot stayed gray. It now also removes and re-adds the matching file: breakpoint once per session (deduped by session + path + line, so no repeated flicker), forcing VS Code to re-issue its own setBreakpoints against the now-loaded script and flip the dot to red. debug: URIs ...

v0.5.8

Changelog

[0.5.2] — 2026

Changed

• App Watchdog uses a quieter default cadence — The watchdog now pings watched app routes every 90 s by default instead of 30 s, reducing background traffic while still catching apps left frozen on remote breakpoints. The Settings panel now offers 1 minute, 90 seconds (default), 2 minutes, and 5 minutes presets; direct VS Code settings values below 60 s are clamped to 60 s.

[0.5.1] — 2026

Fixed

• App/space lists no longer vanish on slow networks or first org-space selection — Loading the service/app list ran every CF CLI call (cf orgs, cf spaces, cf target, cf apps) under a hard 30 s cap. On the first selection of a fresh org/space, or on a slow network / high-latency CF region, cf apps (and the cf target before it) can legitimately take minutes — the cap killed the process mid-fetch with SIGTERM, so the list loaded briefly and then disappeared with a generic Failed to load apps … CF CLI command failed. error. These data-loading commands now use a 10-minute timeout (verified worst case while still guaranteeing the call eventually errors instead of hanging forever). Quick operational commands (cf logout, cf ssh-enabled, cf scale, app-route lookups) keep their fast 30 s cap; cf restart keeps its own 120 s limit.

[0.5.0] — 2026

Added

• App Watchdog — detects CF apps left frozen on a breakpoint — A debug session that ends without proper cleanup (crashed VS Code window, dropped tunnel, missed breakpoint clear) can leave breakpoints armed inside the remote app; the next request that hits them pauses the whole app for every tester. CDS Debug now:
  • records every app started through Start Debug Sessions (timestamp, region, org, space, mapped route, owner window pid) in ~/.cds-debug/watched-apps.json — shared across VS Code windows and surviving restarts, so monitoring resumes even after the window that started the session crashed;
  • pings each watched app's mapped route on an interval (default 30 s, cdsDebug.appWatchdog.pingIntervalSeconds, also on the Settings panel). Liveness is "did the event loop answer at all": any HTTP status from the app counts as alive, while a client-side timeout or a gateway 502/503/504 counts as not responding — the exact signature of a Node process parked on a breakpoint;
  • flags an app only after 2 consecutive failures (network blips don't alarm), shows a status bar warning (N apps are not responding), and clicking it opens an App Watchdog page with per-app status, route, failure reason, watch window, and Stop watching / Check now actions (CDS Debug: Show App Watchdog);
  • skips apps you are actively debugging — while this window has a live debug session for an app, pausing on your own breakpoint is expected, so checks and failure counting are suspended and resume right after the session ends. Entries owned by another still-alive VS Code window are left to that window; a dead owner is taken over by any window;
  • watches each app for 8 hours from its last debug start (cdsDebug.appWatchdog.watchDurationHours, VS Code settings only), then removes it automatically. The whole feature can be disabled with cdsDebug.appWatchdog.enabled.

[0.4.32] — 2026

Fixed

• The Debug Launcher no longer shows an empty panel after selecting org/space/folder — When cf-sync had synced the org/space structure but not yet the space's apps (or stored spaces in the legacy string format), the launcher served the empty topology list as-is: a READY screen with zero app rows and no live fetch — reported by users as "the Debug Launcher is completely blank". An empty topology app list is now treated as no data on both the webview and extension side, falling through to the cached/live cf apps fetch.
• Webview render failures are visible and recoverable instead of a blank/frozen panel — A renderer exception used to leave the panel blank (on first render) or frozen on a stale screen, with no diagnostics. The launcher now has a render error boundary that shows a recovery screen with a "Reload Launcher" button, reports the error (with stack) to the CDS Debug output channel via a new WEBVIEW_ERROR message, forwards window.onerror/unhandledrejection the same way, and ships static fallback content inside the panel so even a script that never runs is not a silent blank page. An unknown screen state now renders the recovery screen instead of an empty string.
• Loading screens can no longer hang forever when the extension config is missing — LOAD_SPACES/LOAD_APPS/START_DEBUG used to return silently when the saved configuration was absent (e.g. after Reset Configuration while the webview retained old state), stranding the user on a spinner. They now post an explicit error back to the panel.
• Stopping from VS Code's debug toolbar (red square) now also clears remote breakpoints — Only the panel's Stop button ran the defensive setBreakpoints([]) pass; the toolbar stop skipped it, leaving the remote Node inspector holding breakpoints until cf restart. The clear now also runs on externally-terminated sessions, through the child sessions that briefly outlive the root (best-effort, time-bounded), and removes the now-dead Package-browser breakpoints from VS Code state when no session survives.
• Breakpoint-clear timeouts sized for slow CF regions — the per-request/total/loadedSources budgets (0.5 s/2 s/1.5 s) could expire on high-latency regions (ap10, jp10), silently resurrecting the "breakpoint survives until cf restart" bug there. Raised to 1.5 s/4 s/3 s; they only bite when the tunnel is half-open.
• Foreign Debug:-named sessions are left alone — a user-defined launch configuration named Debug: <x> no longer triggers CDS Debug's exited-session cleanup on terminate (notifications, status broadcasts, or the opt-in cf restart of an app the extension does not own).

[0.4.31] — 2026

Fixed

• Package Browser loads reliably on slow / high-latency CF regions — Clicking Package after starting a debug session could intermittently fail to load any packages (or time out after ~60 s) on slow orgs such as ca10, because the warm-up depended on polling the loadedSources request at exactly the right moment while the child "Remote Process" session appeared. This is now addressed on three fronts:
  • Push-based source collection — CDS Debug now records the DAP loadedSource events that vscode-js-debug emits for every (including child) session, accumulating package sources continuously instead of relying solely on polling. Sources that arrive between polls — or before the browser is opened — are no longer missed.
  • A single slow loadedSources request no longer aborts the whole warm-up — a per-request timeout is treated as "not ready yet" and retried, instead of failing the entire load. One laggy request on a slow inspector tunnel used to kill the attempt outright.
  • Deadline instead of a fixed attempt count — the warm-up now waits up to a total budget (180 s) for the child session to appear, rather than a hard 60-attempt ceiling, and wakes immediately when a new session starts or a source event arrives.
• More reliable inspector readiness probe — the pre-attach probe now waits for a non-empty /json/list (a real debuggable target) instead of /json/version (inspector metadata only), so vscode-js-debug finds a target immediately and the child session appears dependably.

[0.4.23-pre.1] — 2026

Fixed

• Package Browser (debug:) breakpoints now turn verified (red) once bound — Breakpoints set in node_modules/package sources opened from the Package Browser as debug: URIs (when the .ts is not on disk) were bound and paused execution, but VS Code's gutter stayed gray because the bind happened via customRequest, which the gutter ignores. The breakpoint mirror now nudges VS Code to re-issue its own setBreakpoints by re-adding the breakpoint once per verifying session (keyed by session + path + line, so no repeated flicker), flipping the dot to red. This complements the file: re-verify fix from 0.4.22.

[0.4.23-pre.0] — 2026

Fixed

• The Package Browser returns to the launcher when its debug session ends — Stopping the debugger from VS Code (or the remote server detaching/crashing/reconnecting) while the Package Browser was open used to leave an empty Packages screen with no sources. CDS Debug now detects that the browsed app is no longer attached and navigates back to the app-selection (launcher) screen automatically.

[0.4.23] — 2026

Stable release consolidating the 0.4.7-pre.x line (changes since 0.4.4).

Highlights

• No-install package debugging — the Package Browser opens dependency sources from the running app and no longer writes files into node_modules.
• Reliable package breakpoints — breakpoints in node_modules/package sources show as verified (red) once their script loads; stopping a session clears remote breakpoints so the app no longer stays paused in the Node inspector (no cf restart).
• CF instance counts & safe scaling from the panel, and auto-retrying background topology sync after a failed or canceled run.

[0.4.7-pre.14] — 2026

Fixed

• node_modules breakpoints now show as verified (red) instead of staying gray after the script loads — When a CAP handler in node_modules loads lazily, BreakpointResolver already re-bound the breakpoint via a customRequest (working around vscode-js-debug#1510) so execution paused — but a customRequest does not update VS Code's gutter, so the dot stayed gray. It now also removes and re-adds the matching file: breakpoint once per session (deduped by session + path + line, so no repeated flicker), forcing VS Code to re-issue its own setBreakpoints against the now-loaded script and flip the dot to red. debug: URIs ...

v0.5.7

Changelog

[0.5.2] — 2026

Changed

• App Watchdog uses a quieter default cadence — The watchdog now pings watched app routes every 90 s by default instead of 30 s, reducing background traffic while still catching apps left frozen on remote breakpoints. The Settings panel now offers 1 minute, 90 seconds (default), 2 minutes, and 5 minutes presets; direct VS Code settings values below 60 s are clamped to 60 s.

[0.5.1] — 2026

Fixed

• App/space lists no longer vanish on slow networks or first org-space selection — Loading the service/app list ran every CF CLI call (cf orgs, cf spaces, cf target, cf apps) under a hard 30 s cap. On the first selection of a fresh org/space, or on a slow network / high-latency CF region, cf apps (and the cf target before it) can legitimately take minutes — the cap killed the process mid-fetch with SIGTERM, so the list loaded briefly and then disappeared with a generic Failed to load apps … CF CLI command failed. error. These data-loading commands now use a 10-minute timeout (verified worst case while still guaranteeing the call eventually errors instead of hanging forever). Quick operational commands (cf logout, cf ssh-enabled, cf scale, app-route lookups) keep their fast 30 s cap; cf restart keeps its own 120 s limit.

[0.5.0] — 2026

Added

• App Watchdog — detects CF apps left frozen on a breakpoint — A debug session that ends without proper cleanup (crashed VS Code window, dropped tunnel, missed breakpoint clear) can leave breakpoints armed inside the remote app; the next request that hits them pauses the whole app for every tester. CDS Debug now:
  • records every app started through Start Debug Sessions (timestamp, region, org, space, mapped route, owner window pid) in ~/.cds-debug/watched-apps.json — shared across VS Code windows and surviving restarts, so monitoring resumes even after the window that started the session crashed;
  • pings each watched app's mapped route on an interval (default 30 s, cdsDebug.appWatchdog.pingIntervalSeconds, also on the Settings panel). Liveness is "did the event loop answer at all": any HTTP status from the app counts as alive, while a client-side timeout or a gateway 502/503/504 counts as not responding — the exact signature of a Node process parked on a breakpoint;
  • flags an app only after 2 consecutive failures (network blips don't alarm), shows a status bar warning (N apps are not responding), and clicking it opens an App Watchdog page with per-app status, route, failure reason, watch window, and Stop watching / Check now actions (CDS Debug: Show App Watchdog);
  • skips apps you are actively debugging — while this window has a live debug session for an app, pausing on your own breakpoint is expected, so checks and failure counting are suspended and resume right after the session ends. Entries owned by another still-alive VS Code window are left to that window; a dead owner is taken over by any window;
  • watches each app for 8 hours from its last debug start (cdsDebug.appWatchdog.watchDurationHours, VS Code settings only), then removes it automatically. The whole feature can be disabled with cdsDebug.appWatchdog.enabled.

[0.4.32] — 2026

Fixed

• The Debug Launcher no longer shows an empty panel after selecting org/space/folder — When cf-sync had synced the org/space structure but not yet the space's apps (or stored spaces in the legacy string format), the launcher served the empty topology list as-is: a READY screen with zero app rows and no live fetch — reported by users as "the Debug Launcher is completely blank". An empty topology app list is now treated as no data on both the webview and extension side, falling through to the cached/live cf apps fetch.
• Webview render failures are visible and recoverable instead of a blank/frozen panel — A renderer exception used to leave the panel blank (on first render) or frozen on a stale screen, with no diagnostics. The launcher now has a render error boundary that shows a recovery screen with a "Reload Launcher" button, reports the error (with stack) to the CDS Debug output channel via a new WEBVIEW_ERROR message, forwards window.onerror/unhandledrejection the same way, and ships static fallback content inside the panel so even a script that never runs is not a silent blank page. An unknown screen state now renders the recovery screen instead of an empty string.
• Loading screens can no longer hang forever when the extension config is missing — LOAD_SPACES/LOAD_APPS/START_DEBUG used to return silently when the saved configuration was absent (e.g. after Reset Configuration while the webview retained old state), stranding the user on a spinner. They now post an explicit error back to the panel.
• Stopping from VS Code's debug toolbar (red square) now also clears remote breakpoints — Only the panel's Stop button ran the defensive setBreakpoints([]) pass; the toolbar stop skipped it, leaving the remote Node inspector holding breakpoints until cf restart. The clear now also runs on externally-terminated sessions, through the child sessions that briefly outlive the root (best-effort, time-bounded), and removes the now-dead Package-browser breakpoints from VS Code state when no session survives.
• Breakpoint-clear timeouts sized for slow CF regions — the per-request/total/loadedSources budgets (0.5 s/2 s/1.5 s) could expire on high-latency regions (ap10, jp10), silently resurrecting the "breakpoint survives until cf restart" bug there. Raised to 1.5 s/4 s/3 s; they only bite when the tunnel is half-open.
• Foreign Debug:-named sessions are left alone — a user-defined launch configuration named Debug: <x> no longer triggers CDS Debug's exited-session cleanup on terminate (notifications, status broadcasts, or the opt-in cf restart of an app the extension does not own).

[0.4.31] — 2026

Fixed

• Package Browser loads reliably on slow / high-latency CF regions — Clicking Package after starting a debug session could intermittently fail to load any packages (or time out after ~60 s) on slow orgs such as ca10, because the warm-up depended on polling the loadedSources request at exactly the right moment while the child "Remote Process" session appeared. This is now addressed on three fronts:
  • Push-based source collection — CDS Debug now records the DAP loadedSource events that vscode-js-debug emits for every (including child) session, accumulating package sources continuously instead of relying solely on polling. Sources that arrive between polls — or before the browser is opened — are no longer missed.
  • A single slow loadedSources request no longer aborts the whole warm-up — a per-request timeout is treated as "not ready yet" and retried, instead of failing the entire load. One laggy request on a slow inspector tunnel used to kill the attempt outright.
  • Deadline instead of a fixed attempt count — the warm-up now waits up to a total budget (180 s) for the child session to appear, rather than a hard 60-attempt ceiling, and wakes immediately when a new session starts or a source event arrives.
• More reliable inspector readiness probe — the pre-attach probe now waits for a non-empty /json/list (a real debuggable target) instead of /json/version (inspector metadata only), so vscode-js-debug finds a target immediately and the child session appears dependably.

[0.4.23-pre.1] — 2026

Fixed

• Package Browser (debug:) breakpoints now turn verified (red) once bound — Breakpoints set in node_modules/package sources opened from the Package Browser as debug: URIs (when the .ts is not on disk) were bound and paused execution, but VS Code's gutter stayed gray because the bind happened via customRequest, which the gutter ignores. The breakpoint mirror now nudges VS Code to re-issue its own setBreakpoints by re-adding the breakpoint once per verifying session (keyed by session + path + line, so no repeated flicker), flipping the dot to red. This complements the file: re-verify fix from 0.4.22.

[0.4.23-pre.0] — 2026

Fixed

• The Package Browser returns to the launcher when its debug session ends — Stopping the debugger from VS Code (or the remote server detaching/crashing/reconnecting) while the Package Browser was open used to leave an empty Packages screen with no sources. CDS Debug now detects that the browsed app is no longer attached and navigates back to the app-selection (launcher) screen automatically.

[0.4.23] — 2026

Stable release consolidating the 0.4.7-pre.x line (changes since 0.4.4).

Highlights

• No-install package debugging — the Package Browser opens dependency sources from the running app and no longer writes files into node_modules.
• Reliable package breakpoints — breakpoints in node_modules/package sources show as verified (red) once their script loads; stopping a session clears remote breakpoints so the app no longer stays paused in the Node inspector (no cf restart).
• CF instance counts & safe scaling from the panel, and auto-retrying background topology sync after a failed or canceled run.

[0.4.7-pre.14] — 2026

Fixed

• node_modules breakpoints now show as verified (red) instead of staying gray after the script loads — When a CAP handler in node_modules loads lazily, BreakpointResolver already re-bound the breakpoint via a customRequest (working around vscode-js-debug#1510) so execution paused — but a customRequest does not update VS Code's gutter, so the dot stayed gray. It now also removes and re-adds the matching file: breakpoint once per session (deduped by session + path + line, so no repeated flicker), forcing VS Code to re-issue its own setBreakpoints against the now-loaded script and flip the dot to red. debug: URIs ...

v0.5.6 (0.5.5-pre.0)

Pre-release build published from feature/password-ssh-proxy-tunnel at bf1cca7.

v0.5.5 (0.5.4-pre.0)

Pre-release build published from feature/password-ssh-proxy-tunnel at 368ed0c.

v0.5.4 (0.5.3-pre.0)

Pre-release build published from feature/password-ssh-proxy-tunnel at 3ef46ea.