Debug session never completes (no error, no automation prompt) despite core library working correctly — VS Code 1.138.0, macOS 26.6.2, Apple Silicon

Environment

• VS Code: 1.138.0 (Universal build)
• OS: macOS 26.6.2, Apple Silicon
• Extension: ExtendScript Debugger 2.1.0 (Adobe)
• Target apps tested: Photoshop 2026 (200.064), Illustrator (30.064)

Issue
Running or attaching a debug session via VS Code's Run and Debug panel never completes. Selecting "Launch Script in ExtendScript Engine" and pressing F5 (or using the "Eval in Adobe..." status bar action) produces no visible effect:

• No alert() dialog appears in the target application
• No error appears in the Debug Console or Extension Host logs
• No macOS Automation permission prompt is ever shown, and VS Code never appears under System Settings > Privacy & Security > Automation
• The Run and Debug panel shows a persistent loading/spinner state with no resolution

What I've already ruled out
To narrow this down, I loaded the extension's native module directly via Node, bypassing VS Code entirely:

js

const m = require('.../lib/esdebugger-core/mac/esdcorelibinterface.node');
m.esdInitialize('vscesd', process.pid);
m.esdGetInstalledApplicationSpecifiers();

This succeeds cleanly:

• esdInitialize returns { status: 0 }
• esdIsInitialized() returns true
• esdGetInstalledApplicationSpecifiers() correctly returns all installed Adobe apps, including photoshop-200.064 and illustrator-30.064

I also confirmed:

• No quarantine flags on the extension's binaries (esdcorelibinterface.node, AID.dylib)
• Both are proper universal binaries (arm64 + x86_64)
• Rosetta is installed and functional
• A clean reinstall of the extension didn't change the behavior

Question
Since the native core library correctly initializes and detects installed applications when called directly, the OS-level layer (permissions, binary architecture, quarantine, Rosetta) appears to be fully ruled out. The failure seems to be somewhere in the extension's own session orchestration — the code that calls esdSendDebugMessage / esdPumpSession and wires up the async response handling inside the VS Code extension host — since that layer never surfaces an error or even attempts the automation permission handshake with the target app.

Has anyone seen a similar silent failure with a recent VS Code build (1.13x) on macOS 26.x, and is there a known fix or workaround for getting the debug session's message pump/handshake to actually initiate?