Windows: node not recognized in first Warp session until app restart

[yimity]

Pre-submit Checks

• I have searched Warp bugs and there are no duplicates
• I have searched Warp known issues page and my issue is not there
• I have an issue with AI and have included the debugging ID (Optional, but helps expedite the AI quality fix). Debugging ID instructions
• I have technical issue and have included the logs (optional, but helps expedite the bug fix). Log instructions

Describe the bug

Summary
Intermittent startup environment issue on Windows where node is unavailable in the first Warp session and only works after restarting Warp.

Problem
In Warp on Windows, running node -v sometimes fails with “The term node is not recognized...” in a fresh session (often on first open or after updating Warp). Closing and reopening Warp makes the same command work.

Expected behavior
node should be resolvable and executable in every new Warp session without restarting the app.

Actual behavior
In some fresh launches, node -v fails with: node: The term 'node' is not recognized as a name of a cmdlet, function, script file, or executable program.... After closing and reopening Warp, node -v works.

Reproduction steps or desired workflow

1. Open Warp on Windows (issue appears intermittently, often on first open or after updating Warp).
2. In a PowerShell tab, run node -v.
3. Observe that node is not recognized.
4. Close Warp completely and reopen it.
5. Run node -v again and observe that it now works.

Artifacts
Error text from affected session:
node: The term 'node' is not recognized as a name of a cmdlet, function, script file, or executable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.

Warp version
v0.2026.04.29.08.57.stable_02

Operating system
Windows 10.0.26100

To reproduce

dont know how to reproduce.

Expected behavior

No response

Screenshots, videos, and logs

No response

Operating system (OS)

Windows

Operating system and version

Windows 10.0.26100

Shell Version

No response

Current Warp version

No response

Regression

No, this bug or issue has existed throughout my experience using Warp

Recent working Warp date

No response

Additional context

No response

Does this block you from using Warp daily?

No

Is this an issue only in Warp?

Yes, I confirmed that this only happens in Warp, not other terminals.

Warp Internal (ignore): linear-label:b9d78064-c89e-4973-b153-5178a31ee54e

None

[oz-for-oss]

@yimity

Here's what I found while triaging this issue:

This looks closely related to #8920, which reports npm/PATH missing in Windows PowerShell after a Warp update until a manual restart. I’m not marking this as a duplicate because only one matching open issue was found.

I have a few follow-up questions before I can narrow this down:

1. Was Node installed via nvm-windows/NPM for Windows, the Node MSI installer, Scoop/winget, Volta, or another manager?
2. In a failing Warp session, does the redacted $env:Path include the directory that contains node.exe?

Reply in-thread with those details and the triage workflow will automatically re-evaluate the issue and update the diagnosis, labels, and next steps.

Maintainer details

I concluded that windows PowerShell sessions can start with a PATH that does not resolve Node until Warp is fully restarted, likely due to stale or incomplete Windows environment block construction on first launch or after update..

Triage

This is a Windows-specific shell environment bug. In a fresh PowerShell session, node -v is not resolved until Warp is restarted; the same pattern appears in related issue #8920 for npm/NVM after updates.

Reproducibility

Medium. The report includes the command, error text, OS/version, Warp version in the description, Warp-only confirmation, and restart workaround, but the failure is intermittent and no failing-session PATH or log output is attached.

Likely root cause

Warp constructs the Windows shell process environment in app/src/terminal/local_tty/windows/environment.rs by starting with the current process environment, then reading HKLM/HKCU environment registry values, merging user Path into system Path, expanding Path-like registry values, and serializing the result into the environment block passed to CreateProcessW in app/src/terminal/local_tty/windows/mod.rs. The symptom is consistent with the first launch or post-update Warp process having stale or incomplete Node-related PATH entries before PowerShell starts; a full Warp restart then refreshes the app process environment and node resolves correctly. PowerShell is launched with -NoProfile, so profile scripts are less likely to be the source of Node PATH setup for this session.

Duplicate check

Found one close open issue: #8920 reports npm/PATH missing in a Windows PowerShell session after update until a manual restart. Under the repository dedupe rule, a single close match is not enough to mark this issue as a duplicate.

Follow-up needed

• Was Node installed via nvm-windows/NPM for Windows, the Node MSI installer, Scoop/winget, Volta, or another manager?
• In a failing Warp session, does the redacted $env:Path include the directory that contains node.exe?

Question reasoning

1. Was Node installed via nvm-windows/NPM for Windows, the Node MSI installer, Scoop/winget, Volta, or another manager? — The closest related report involves NPM for Windows/nvm-windows, and the likely code path depends on how Node's PATH entries are added to the Windows user/system environment.
2. In a failing Warp session, does the redacted $env:Path include the directory that contains node.exe? — This distinguishes a missing PATH/environment-block problem from a PowerShell command-resolution or executable-installation problem, and the agent cannot inspect the reporter's failing Windows environment.

This is my automated analysis and may be incorrect. A maintainer will verify the details.

Powered by Oz