[VSCE] Check if `.env` is a file, not a folder, before trying to read it

[drewbanin]

Ran into this here: https://dbt-labs.slack.com/archives/C0895CBHERZ/p1749247382945849

Fails with an error like:

2025-06-06 17:08:27.167 [error] Error: EISDIR: illegal operation on a directory, read
	at Object.readSync (node:fs:751:18)
	at tryReadSync (node:fs:425:20)
	at Object.readFileSync (node:fs:479:19)
	at t.readFileSync (node:electron/js2c/node_init:2:10175)
	at wh (/Users/brandon/.cursor/extensions/dbtlabsinc.dbt-0.2.6/dist/extension.js:215:6609)
	at t.createTask (/Users/brandon/.cursor/extensions/dbtlabsinc.dbt-0.2.6/dist/extension.js:216:719)
	at t.createAndRun (/Users/brandon/.cursor/extensions/dbtlabsinc.dbt-0.2.6/dist/extension.js:216:330)
	at Dh.runWorkspaceCommand (/Users/brandon/.cursor/extensions/dbtlabsinc.dbt-0.2.6/dist/extension.js:219:611)
	at /Users/brandon/.cursor/extensions/dbtlabsinc.dbt-0.2.6/dist/extension.js:314:3595
	at async Wet.h (file:///Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/api/node/extensionHostProcess.js:135:33097) dbt.openBuildMenu {"value":"dbtLabsInc.dbt","_lower":"dbtlabsinc.dbt"}

It's a tough one to debug because 1) the path is not shown in the error and 2) it impacts both LSP startup + dbt invocations (both code paths try to read env vars)

[fa-assistant]

🧹 Stale Issue Detected

This issue has had no meaningful activity for 210 days.

If this is still relevant, please:

• Comment with an update, or
• Add the cleanup/keep label to exempt it from future cleanup scans.

If no action is taken within 30 days, this issue will be scheduled for auto-close with a 7-day grace period.

cc @akbog — as assignee(s), can you confirm whether this is still active?

---

This notice was posted by the Fusion Issue Cleanup workflow.

[davidharting]

Still an issue. A few possible solutions:

• CLI / LSP side: Tolerate this problem and ignore .env/ folders
• CLI / LSP side: Emit clearer error message when this happens (tell us what folder you were trying to read!)
• VSCE side: Detect this situation and raise a very clear user-facing error message.

I think we could consider this in the domain of VSCE and do one of these solutions, even if we end up making a code change in fusion