Why are my macOS studio computers After Effects unintentionally deploying (or falling back to) the Torq/NAPI JS engine instead of Adobe’s standard expression engine.

Hello Adobe AE Team,

I am experiencing a reproducible issue across four identical Mac Studio units (Apple M3 Ultra, 256 GB RAM) running macOS Sequoia 15.5, where After Effects is loading the Torq/NAPI JavaScript engine instead of the Adobe JavaScript engine.

Across AE versions 25.4, 25.5, and 26.0, the following diagnostic expressions always return:

$.engineName → "torq/napi"
typeof(TextDocument) → "undefined"

This indicates that AE is not loading the expected Adobe JS engine and instead is loading a fallback runtime that does not support TextDocument APIs.

As a result, all of the following APIs fail:

• new TextDocument()
• .style
• .fontSize
• .leading
• .setFontSize()
• .setLeading()
• .setJustification()

I have thoroughly eliminated all environmental causes:

✅ Confirmed no Torq, Fusion, NAPI, or Resolve frameworks in system paths
✅ Confirmed no PATH or DYLD overrides
✅ Confirmed no per-user shell modifications
✅ Confirmed no MDM restrictions
✅ Confirmed Full Disk Access for AE and Terminal
✅ Confirmed quarantine flags cleared
✅ Confirmed new clean macOS user profiles
✅ Confirmed fresh prefs reset
✅ Confirmed reinstalls of all tested AE versions
✅ Confirmed the behavior is identical on all systems

Given that:

• every AE version tested (25.4, 25.5, 26) loads "torq/napi",
• all systems are clean and identical, and
• TextDocument is missing across the board,

this strongly suggests that current macOS After Effects builds are unintentionally deploying (or falling back to) the Torq/NAPI JS engine instead of Adobe’s standard expression engine.

My team needs confirmation of this issue and guidance on:

1. Whether this engine is expected in these builds
2. Whether a patch or update is planned
3. Whether there is a way to force AE to load the correct Adobe JS engine
4. A temporary workaround for restoring TextDocument functionality

Our workflow depends heavily on TextDocument-based rigs, so this is a production blocker.

Thank you,  -Chad