Unable to make it work on Windows 11

[PrasOnWeb]

GitHub Issue: _copyMsixPackageLocal fails on Windows 11 25H2 — exit code 9, process dies < 1s

Repository: tradesdontlie/tradingview-mcp v1.0.0

Environment

OS: Windows 11 25H2 (Build 10.0.26200)
Node.js: v24.16.0
TradingView Desktop: 3.3.0.7992 (MSIX / Windows Store)
Package full name: TradingView.Desktop_3.3.0.7992_x64__n534cwy3pjxzj
What happens

Both code paths in launch() fail:

Path 1 — direct WindowsApps launch (spawn from C:\Program Files\WindowsApps...\TradingView.exe):
Process exits immediately with exit code 9 within < 1 second. _spawnFailedEarly catches this within the 1500ms grace window.

Note: cmd.exe start "" (ShellExecute) DOES launch TV successfully from the same path, but --remote-debugging-port=9222 is silently stripped by the MSIX activation broker — CDP never binds. This is a separate known issue.

Path 2 — local copy fallback (_copyMsixPackageLocal → %LOCALAPPDATA%\tradingview-mcp...\TradingView.exe):
Copy completes with all 116/116 files present. But spawning the local copy also exits with exit code 9 within < 1 second:

// Exact reproduction of _spawnDetached:
const {spawn} = require('child_process');
const c = spawn(localExe, ['--remote-debugging-port=9222'], {detached:true, stdio:'ignore'});
c.on('exit', (code) => console.log('EXIT code=' + code)); // → EXIT code=9
Root cause hypothesis

Exit code 9 on Windows 11 25H2 appears to be TradingView's Electron main process calling GetCurrentPackageId() (or similar MSIX identity API) at startup. When the call fails — either because the exe was invoked via direct CreateProcess (bypassing the MSIX activation broker) or because it's running outside WindowsApps\ with no registered package identity — TV exits immediately with code 9.

This is a regression in newer Windows 11 builds where Electron apps explicitly validate package identity even when run from a local copy. The local copy approach relies on the assumption that running outside WindowsApps\ skips the identity check — that is no longer true on 25H2.

Key distinction: cmd.exe start "" uses ShellExecuteEx which routes MSIX apps through the activation broker (TV runs, no crash) — but Node.js spawn / PowerShell Start-Process use CreateProcess directly, bypassing the broker (TV exits code 9).

Suggested fix / investigation

In _spawnDetached, try passing shell: true for the WindowsApps path — this routes through cmd.exe start, which uses ShellExecute and activates the MSIX broker. It still won't pass --remote-debugging-port, but it narrows the problem.
For the local copy path: Windows has an undocumented SetCurrentPackagePath() API (or MSIX_DEBUGGER_LAUNCHING env var) that can fake package identity — worth investigating whether this lets the local copy start.
Alternatively, document that MSIX TV Desktop on Windows 11 22H2+ may not work and suggest the Chrome browser workaround (chrome.exe --remote-debugging-port=9222 --user-data-dir= https://tradingview.com/chart/).
Diagnostic commands to reproduce

1. Confirm MSIX install

Get-AppxPackage -Name "TradingView.Desktop" | Select-Object Version, PackageFullName

2. Confirm local copy exists with all files

$d = "$env:LOCALAPPDATA\tradingview-mcp\TradingView.Desktop_3.3.0.7992_x64__n534cwy3pjxzj"
(Get-ChildItem $d -Recurse -File).Count # → 116

3. Reproduce the exit code 9

node -e "
const {spawn}=require('child_process');
const c=spawn('$d\TradingView.exe',['--remote-debugging-port=9222'],{detached:true,stdio:'ignore'});
c.on('exit',code=>console.log('EXIT code='+code));
"

Output: EXIT code=9

[Waldico]

Confirming independent reproduction on a separate Windows 10 machine (fresh setup, not related to the OP's environment):

Environment

• Windows 10 Home (Build 10.0.19045)
• TradingView Desktop: 3.3.0.7992 (MSIX, TradingView.Desktop_3.3.0.7992_x64__n534cwy3pjxzj), installed both via Microsoft Store and via the tvd-packages.tradingview.com App Installer — same package version both times
• Node v24.18.0
• Fresh clone of main at time of testing

What happened

1. tv_launch → spawn EPERM (uncaught synchronous throw from child_process.spawn on the direct WindowsApps path — this bypasses the _spawnFailedEarly early-failure detection entirely since the throw happens before _spawnDetached even returns a child object). Patched health.js locally to wrap that initial spawn in try/catch so it falls through to the local-copy fallback — confirmed the fallback never ran before this patch on our machine either, so this synchronous-throw case may be worth handling upstream regardless of the exit-code-9 issue below.
2. After the try/catch fix, _copyMsixPackageLocal fallback runs correctly (copy completes, all files present) — but the copied TradingView.exe reliably self-terminates ~3-6s after launch, every time, across two independent fresh copies. No crash dialog, no Windows Error Reporting event, no app-level log written (checked %APPDATA%\TradingView and %LOCALAPPDATA%\Packages\TradingView.Desktop_n534cwy3pjxzj for any file modified in the launch window — nothing).
3. Direct execution from WindowsApps via interactive PowerShell (Start-Process, not through Node) also fails, with an explicit Odmowa dostępu / Access is denied — so this is OS-level ACL enforcement, not sandboxing specific to a spawning process.

This matches the exit-code-9 / package-identity-check hypothesis in the OP exactly — just adding a second data point on a different Windows build (10 vs 11) and a different distribution channel (both Store and tvd-packages.tradingview.com installers produce the identical MSIX package/version), so this doesn't look Windows-11-specific or Store-specific.

+1 on documenting this as a known limitation for current MSIX builds, and/or the Chrome-browser-workaround suggestion in the OP, since both launcher code paths appear to be dead ends for 3.3.0.7992 as currently built.