dsh prints failed to load .env: EISDIR when a directory named .env exists in the working directory

[Acidmoon]

Environment

• OS: Windows 11 (PowerShell 7.6.3)
• Node.js: v24.3.0, npm 11.4.2
• @deepseek-ai/dsh: 0.1.0-rc.6 (installed via npm install -g @deepseek-ai/dsh; also reproduced via npx @deepseek-ai/dsh web)
• @deepseek-ai/dsh-app-boot: 0.1.0-rc.6

Summary

When a directory named .env exists in the directory where dsh is invoked (or in the Harness home, ~/.dsh), every boot prints:

dsh: failed to load .env: Error: EISDIR: illegal operation on a directory, read

A directory can never be a valid dotenv file, so according to the documented semantics ("missing files fall back to the ambient environment", see the doc comments on readEnvLayer / loadEnv) this case should be treated like a missing file and skipped silently — not reported as a misconfiguration. The message is non-fatal (the profile still boots), but it reads like a hard error and is confusing.

Steps to reproduce

1. Create an empty directory named .env in the current directory:

   mkdir .env

2. Boot any profile from that directory:

   dsh --profile web

   (In my case the .env directory was at the home directory C:\Users\<user>\.env, and dsh was run from that same directory, which is how the invoking-directory layer picked it up.)

Expected behavior

No .env diagnostics at all — the directory is not a dotenv file, so the loader falls back to the ambient environment, and boot proceeds cleanly (dsh web: http://127.0.0.1:3080, etc.).

Actual behavior

PS C:\Users\...> dsh --profile web
dsh: failed to load .env: Error: EISDIR: illegal operation on a directory, read

The boot continues afterwards (the line is a warning, not a fatal error).

Root cause

In packages/boot/app-boot (@deepseek-ai/dsh-app-boot), both .env readers only treat ENOENT as "no file", so any other read error is reported:

• readEnvLayer() — readFileSync(resolve(dir, ".env"), "utf8"); the catch warns unless error?.code !== "ENOENT". This is the function that produced the reported line: apps/cli's bin.js calls loadLayeredEnv("dsh"), which reads the invoking-directory layer and the ~/.dsh user layer through readEnvLayer. In the published package this is lib/index.js around lines 695–713.
• loadEnv() — process.loadEnvFile(resolve(dir, ".env")); same ENOENT-only filter. Published lib/index.js around lines 611–617.

When the resolved path is a directory, fs.readFileSync throws EISDIR (verified standalone: EISDIR: illegal operation on a directory, read), which does not match the ENOENT filter and is therefore printed as "failed to load .env". (process.loadEnvFile on a directory throws ERR_INVALID_ARG_TYPE on Node 24 — a different code, but the same bug: a non-file .env is reported instead of skipped.)

Suggested fix

Treat a non-file .env as "no env file" in both readers, e.g.:

if (error?.code !== "ENOENT" && error?.code !== "EISDIR" && error?.code !== "ENOTDIR")
  warn(...);

or, more robustly, check before reading:

const path = resolve(dir, ".env");
if (!existsSync(path)) return;
if (!statSync(path).isFile()) return; // a directory named `.env` is not a dotenv file

Additional context

• This is easy to hit on Windows, where .env is a legal folder name; here an empty C:\Users\<user>\.env directory existed in the home directory.
• Both layers (cwd/.env and ~/.dsh/.env) go through the same readEnvLayer guard, so the same fix covers both.
• Severity: minor (non-fatal warning; boot proceeds). 0.1.0-rc.6 is the latest published version at the time of writing, so this is not fixed by upgrading.

[ltyfulan9]

Thanks for the report. I reproduced this against commit 47f9438. The loader has two independent .env reads, and both currently attempt to read the path without first checking that it is a regular file, so a directory named .env surfaces EISDIR.\n\nI prepared a minimal local patch (commit b15c8a3): missing paths and non-regular paths are silently skipped, while read failures for regular files keep the existing warning behavior. Layered precedence and bootstrap-only validation remain unchanged. Focused tests pass (52/52), along with package TypeScript, Oxlint, and doc-sync (28/28).\n\nSince external PRs are currently not accepted, could a maintainer confirm whether this behavior and patch direction fit the project expectations? I can provide the patch or adapt it to the project conventions.