Summary

In Illustrator 30.8.0, the Adobe ExtendScript Debugger extension for VS Code (v2.1.0) can no longer attach to or launch scripts. Rolling back to 30.7.0 fixes it completely, with no other change to VS Code, the extension, or the launch configuration — so this is a regression introduced between 30.7 and 30.8.

The failure is narrow and specific: in 30.8, Illustrator's ExtendScript debug (#estk) channel accepts the debugger's <connect/> handshake but never sends any response. The message is delivered successfully — the core library returns status: 0 with a valid serial number — and then nothing comes back, indefinitely.

In 30.7 the identical request returns the engine list in ~600ms.

Everything else about Illustrator scripting is healthy in 30.8:

• Scripts run normally from File > Scripts and via AppleScript do javascript.
• Illustrator answers ordinary BridgeTalk messages in well under a second.
• ScriptingSupport.aip is loaded, and the debug API is still present in the binary.

Only the debugger's channel is dead.

Regression Range

Illustrator version Debugger attaches?
30.7.0 Yes — engine list returned in ~604ms
30.8.0 No — no response, indefinitely

Environment

Illustrator (broken): 30.8.0
Illustrator (last known good): 30.7.0
InDesign (control, works): 21.5.1.73
macOS: 26.6.2 (build 25G83)
Hardware: Apple M1 (arm64)
VS Code: 1.135.0 (arm64)
ExtendScript Debugger extension: 2.1.0
ExtendScript engine (both apps): $.version 4.5.6, $.build 80.1060872
BridgeTalk specifier: illustrator-30.064 (unchanged across 30.x)

Steps to Reproduce

1. On macOS with Illustrator 30.8 installed, launch Illustrator.
2. In VS Code, install the Adobe ExtendScript Debugger extension (v2.1.0).
3. Use this launch configuration — the exact configuration that works correctly under 30.7:

   {
       "type": "extendscript-debug",
       "request": "attach",
       "name": "Attach--transient",
       "hostAppSpecifier": "illustrator",
       "engineName": "transient"
   }

1. Start the debug session..

Also reproduces with:

• "request": "launch" instead of "attach".
• hostAppSpecifier omitted entirely (choosing Illustrator from the extension's host-application picker).
• An explicit "hostAppSpecifier": "illustrator-30.064".
• A freshly generated, otherwise-default launch.json.

Expected Result

The debugger attaches and Illustrator returns its engine list, as it does under 30.7:

<engines engine=""><engine name="main" state="active"/><engine name="transient" state="active"/></engines>

Actual Result

Under 30.8 the debug session never establishes. Illustrator sends no response of any kind to the <connect/> request. The request does not error — it simply never completes.

---

Evidence

All probes below were run through the extension's own native core (esdebugger-core/mac/esdcorelibinterface.node, from ExtendScript Debugger 2.1.0), loaded into VS Code's Electron runtime and driven with the same esdSendDebugMessage / esdPumpSession calls the extension itself makes. This removes VS Code, launch configurations, and the extension UI from the picture entirely.

1. The <connect/> handshake — 30.7 vs 30.8

Illustrator 30.7 — works:

=== connect illustrator-30.064 ===
send -> {"status":0,"serialNumber":10}
  [605ms] {"target":"vscesd_45522-2.0#dbg",
           "sender":"illustrator-30.064#estk",
           "type":"ExtendScript",
           "body":"<engines engine=\"\">
                     <engine name=\"main\" state=\"active\"/>
                     <engine name=\"transient\" state=\"active\"/>
                   </engines>",
           "serialNumber":10,"resultSerial":3}

Illustrator 30.8 — no response:

=== connect illustrator-30.064 ===
send -> {"status":0,"serialNumber":2}
  NO RESPONSE after 15093ms

Identical machine, identical VS Code, identical extension build, identical call. The only variable is the Illustrator version.

2. InDesign as a same-machine control

InDesign, probed in the same session while Illustrator 30.8 was failing, responds immediately:

=== connect indesign-21.064 ===
send -> {"status":0,"serialNumber":1}
  [759ms] {"sender":"indesign-21.064#estk",
           "body":"<engines engine=\"\">
                     <engine name=\"main\" state=\"active\"/>
                     <engine name=\"ConvertURLToHyperlinks\" state=\"active\"/>
                     <engine name=\"ConvertFootnoteToEndnote\" state=\"active\"/>
                   </engines>", …}

So the debugger core, the native module, and the host-side protocol all work on this machine — just not with Illustrator 30.8.

3. Application discovery is not the problem

Under both 30.7 and 30.8 the core reports Illustrator as installed and running, under the same specifier:

installedSpecifiers: {"status":0,"specifiers":[
    "illustrator-30.064","indesign-21.064","bridge-16.064",
    "aftereffects-26.0","audition-26.0","photoshop-200.064"]}

illustrator-30.064 installed: {"status":0,"isInstalled":true}
illustrator-30.064 running:   {"status":0,"isRunning":true}

BridgeTalk.appSpecifier, queried from inside Illustrator, returns illustrator-30.064 in both versions. The specifier does not change across the 30.x line.

4. Illustrator's ordinary BridgeTalk messaging is fine in 30.8

A full BridgeTalk round-trip sent from InDesign to Illustrator 30.8 succeeds normally:

illustrator-30.064 [916ms] -> OK: illustrator-30.064
illustrator-30.064 [842ms] -> OK: main|30.8.0|4.5.6

Illustrator is reachable and responsive on the normal messaging channel. Only the debug channel is silent. (Round-trip latency rises to 8–18s when Illustrator is backgrounded, which appears to be ordinary background throttling and is not the cause — the debug channel returns nothing even with Illustrator frontmost.)

5. The ExtendScript engine is identical to InDesign's

                                 Illustrator 30.8             InDesign 21.5.1

$.version 4.5.6 4.5.6
$.build 80.1060872 80.1060872
$.engineName main main

Not an engine-version mismatch between app and debugger.

6. The debug API is still present in Illustrator 30.8's binary

AdobeExtendScript.framework inside Illustrator 30.8 still exports the full debug surface — ScScript::DebugAPI::command, setBreakpoints, getStackTrace, getContextInfo, debugBreak, enterDebugMode / leaveDebugMode, and others. Illustrator exports more debug symbols than InDesign (60 vs 35).

ScriptingSupport.aip is present and confirmed loaded into the running process:

/Applications/Adobe Illustrator 2026/Adobe Illustrator.app/Contents/
    Required/Plug-ins/Extensions/ScriptingSupport.aip/Contents/MacOS/ScriptingSupport

The capability is compiled in and loaded; it simply does not answer.

7. Not a "no active engine" condition

The handshake was repeated while a script was actively executing inside Illustrator 30.8 (a 25-second $.sleep), in case the debug endpoint only materialises alongside a live engine:

send -> {"status":0,"serialNumber":1}
  NO RESPONSE while script running (20076ms)

Still silent.

---

Impact

In 30.8, ExtendScript debugging is completely unavailable — no breakpoints, no stepping, no variable inspection, no watch expressions. For anyone maintaining non-trivial Illustrator scripts this removes the only real debugging tool, leaving $.writeln logging and alert-based tracing as the only options.

The Adobe ExtendScript Debugger is the officially supported successor to the ExtendScript Toolkit, so there is no alternative debugger to fall back on.

Workaround

Roll back to Illustrator 30.7 (Creative Cloud → Other Versions).

---

AI notice: the troubleshooting and research was heavily facilitated by Claude Code Opus 5.