process.cwd() fails in a not usefully descriptive way
Version
22.14.0
Platform
macOS Sequoia 15.1.1
Subsystem
process
What steps will reproduce the bug?
~/Code/platformatic via v22.14.0 on ☁️ (us-east-1)
❯ mkdir lol
~/Code/platformatic via v22.14.0 on ☁️ (us-east-1)
❯ cd lol
Code/platformatic/lol on ☁️ (us-east-1)
❯ rm -rf ../lol
Code/platformatic/lol on ☁️ (us-east-1)
❯ node -p "process.cwd()"
node:internal/bootstrap/switches/does_own_process_state:142
cachedCwd = rawMethods.cwd();
^
Error: ENOENT: no such file or directory, uv_cwd
at process.wrappedCwd [as cwd] (node:internal/bootstrap/switches/does_own_process_state:142:28)
at [eval]:1:9
at runScriptInThisContext (node:internal/vm:209:10)
at node:internal/process/execution:449:12
at [eval]-wrapper:6:24
at runScriptInContext (node:internal/process/execution:447:60)
at evalFunction (node:internal/process/execution:87:30)
at evalScript (node:internal/process/execution:99:3)
at node:internal/main/eval_string:74:3 {
errno: -2,
code: 'ENOENT',
syscall: 'uv_cwd'
}
Node.js v22.14.0
How often does it reproduce? Is there a required condition?
Always
What is the expected behavior? Why is that the expected behavior?
Could be made clearer that this is a failure of process.cwd() as the stack trace makes no mention of it. One may make the connection by context, but not necessarily--it's non-obvious. If this was triggered by a process.cwd() deep in your code somewhere it could be quite confusing.
It'd also probably be useful to explain the possible scenario in which this could be triggered--the directory the process was working in was deleted somehow.
What do you see instead?
Error: ENOENT: no such file or directory, uv_cwd
at process.wrappedCwd [as cwd] (node:internal/bootstrap/switches/does_own_process_state:142:28)
at [eval]:1:9
at runScriptInThisContext (node:internal/vm:209:10)
at node:internal/process/execution:449:12
at [eval]-wrapper:6:24
at runScriptInContext (node:internal/process/execution:447:60)
at evalFunction (node:internal/process/execution:87:30)
at evalScript (node:internal/process/execution:99:3)
at node:internal/main/eval_string:74:3
Additional information
No response
I'm going to take this as a "good first issue" if there are no objections.
Can i contribute to this issue?
Hi — I’d like to take this one.
I’ve reproduced the behavior on macOS 15.1.1 (Node 22.14.0). When the current working directory is deleted and process.cwd() is called, the stack trace shows an internal uv_cwd failure rather than clearly pointing to process.cwd().
Proposed direction:
Improve the error message so it explicitly mentions process.cwd() as the source.
Optionally add a short hint about the cause (e.g., “The current working directory no longer exists”).
Confirm this path is triggered through uv_cwd and adjust the wrapping in process.wrappedCwd accordingly, without changing the underlying errno or breaking existing consumers.
Plan / next steps:
Reproduce across supported OSes (macOS, Linux, Windows) to confirm parity.
Update the error handling in process.wrappedCwd to include a clearer message.
Add a regression test in test/parallel/test-process-cwd-deleted-dir.js verifying both the throw and message content.
If that approach sounds acceptable, could you please assign this issue to me? I’ll open a PR with a draft fix and the test update.
I want to work on this issue. Please assign it to me, or let me know if I can start. Thanks!
Just open a PR. You don't need to ask permission. 😅
Thanks for the go-ahead! I couldn’t locate where process.cwd() error handling is defined. Could you point me to the right file or code section? 😊
I noticed this issue. Have you tried checking the error logs or console output? That might help narrow down the root cause. I'd be happy to help investigate if you can share more details about your environment (OS, version, etc.).