Windows: TradingView installs as MSIX package, WindowsApps folder blocks CDP launch (Access Denied)

[chrislin2k]

Setting up the MCP on Windows 10 and hit a blocker at the TradingView launch step.

Issue:
TradingView Desktop (downloaded both from Microsoft Store and directly from
tradingview.com) installs as an MSIX package into:

C:\Program Files\WindowsApps\TradingView.Desktop_3.3.0.7992_x64__\TradingView.exe

Windows locks this folder tightly (package SID isolation), so launching
with the debug flag fails even from an elevated/Administrator PowerShell:

& "C:\Program Files\WindowsApps\TradingView.Desktop_3.3.0.7992_x64__\TradingView.exe" --remote-debugging-port=9222

Result:
Program 'TradingView.exe' failed to run: Access is denied

Also tried granting execute permission directly via icacls (as admin):

icacls "C:\Program Files\WindowsApps\TradingView.Desktop_3.3.0.7992_x64__" /grant "$env:USERNAME:(OI)(CI)RX" /T

Result:
Access is denied.
Successfully processed 0 files; Failed processing 1 files

Environment:

• Windows 10
• TradingView Desktop 3.3.0.7992 (installed via tvd-packages.tradingview.com, .msix package)
• No standalone (non-MSIX/non-WindowsApps) build appears to be available for Windows

Question:
Does the setup guide assume a non-Store/non-MSIX install of TradingView Desktop
on Windows? If so, is there a known source for that build, or a documented
workaround for launching an MSIX-packaged app with --remote-debugging-port
on Windows 10? Happy to test any suggested approach and report back.

[tradesdontlie]

You hit a known Windows failure class, and it's already fixed on main — please git pull and try again; your clone predates the fix.

What changed (PRs #52, #316, #317, all verified against real MSIX installs):

• tv_launch now resolves MSIX installs via Get-AppxPackage (no admin needed), tries the direct launch first, and — on exactly your symptom, WindowsApps Access is denied — automatically falls back to copying the package to %LOCALAPPDATA%\tradingview-mcp\ (one-time, ~330 MB) and launching from the copy. The copied instance keeps your login, layouts, and chart state, and CDP binds normally. When the fallback was used, the tool result includes "msix_local_copy": true.
• scripts\launch_tv_debug.bat got the same detection fix.
• All CDP traffic now uses 127.0.0.1 instead of localhost (some Windows machines resolve localhost to IPv6 first, which Electron's debug server doesn't listen on).

To answer your questions directly:

1. No, there's no non-MSIX Windows build anymore — MSIX is the only distribution, which is why we made tv_launch handle it.
2. The manual workaround (if you want to launch outside the tool) is the same copy trick — reading files out of WindowsApps by exact path is allowed even where executing them isn't:

$pkg = (Get-AppxPackage TradingView.Desktop).InstallLocation
Copy-Item "$pkg\*" "$env:LOCALAPPDATA\tradingview-mcp\TradingView" -Recurse -Force
& "$env:LOCALAPPDATA\tradingview-mcp\TradingView\TradingView.exe" --remote-debugging-port=9222

3. Please don't icacls on WindowsApps — as you found, it fails, and partial ACL changes there can break app servicing.

The SETUP_GUIDE has been updated with all of this (#332) — it was indeed still describing the legacy non-MSIX path, thanks for surfacing that.

Two more tips:

• After pulling, tv_health_check now tells you when your local clone is behind (update.update_available: true), so you'll know when to pull in the future.
• You're on TV 3.3.0, which is newer than the builds the copy-fallback was verified on (3.0–3.1) — it should be version-independent, but please report back either way, especially the msix_local_copy field from your tv_launch result. If 3.3.0 behaves differently we want to know fast.

[chrislin2k]

I pulled the latest changes (PR #332) and confirmed the new code is present. launch_tv_debug.bat still reports that TradingView is running but CDP never becomes available on port 9222. I also confirmed the repository now contains the tv_launch implementation with msix_local_copy support. However, I haven't yet been able to invoke tv_launch through my MCP client, so I can't provide the msix_local_copy result. Could you clarify the intended way to execute tv_launch on Windows? Is it expected to be called only through Claude Code/Desktop after the MCP server is connected, or is there a standalone way to trigger it for testing?

[yudin-s]

The guide/script no longer needs a non-MSIX install, but launching an MSIX app by directly executing the WindowsApps path is the fragile part.

In Windows packaged apps, C:\Program Files\WindowsApps\... is not meant to be treated like a normal program directory, even from an elevated shell. So this failure is expected:

& "C:\Program Files\WindowsApps\TradingView.Desktop_...\TradingView.exe" --remote-debugging-port=9222

The repo's current Windows launcher tries to avoid enumerating WindowsApps directly. It first resolves the package via PowerShell:

Get-AppxPackage -Name 'TradingView.Desktop'

then starts the resolved TradingView.exe with:

start "" "%TV_EXE%" --remote-debugging-port=%PORT%

So I would try the bundled script instead of running the WindowsApps executable path manually:

scripts\launch_tv_debug.bat 9222

If TradingView starts but CDP never appears, the script's own message points to the next workaround: use the tv_launch MCP tool, which falls back to launching from a local copy of the MSIX package. That is probably the intended workaround for Windows builds where the packaged app blocks or drops the debug port.

One more practical check: after launching, test http://127.0.0.1:9222/json/version, not localhost, because the script explicitly uses 127.0.0.1 to avoid IPv6 ::1 resolution issues on some Windows machines.

If that gets CDP reachable, please mark it as answered.

[chrislin2k]

I pulled the latest changes (PR #332) and confirmed the new code is present. launch_tv_debug.bat still reports that TradingView is running but CDP never becomes available on port 9222. I also confirmed the repository now contains the tv_launch implementation with msix_local_copy support. However, I haven't yet been able to invoke tv_launch through my MCP client, so I can't provide the msix_local_copy result. Could you clarify the intended way to execute tv_launch on Windows? Is it expected to be called only through Claude Code/Desktop after the MCP server is connected, or is there a standalone way to trigger it for testing?

[yudin-s]

Small addition to the maintainer answer: yes, there is a standalone CLI path.

From the repo root, before global install, run node src/cli/index.js launch. After npm link, the same command is tv launch. Then check the result with node src/cli/index.js status or tv status.

The MCP path is still tv_launch after the server is connected, but the CLI route should let you test the MSIX copy fallback without first getting your MCP client to expose the tool. If that still leaves CDP unavailable, the useful output to share is the JSON from launch plus status, especially any msix_local_copy field or Windows launch error.