[H-maximedelpit]

⚠️ Warning notice. Spend several hours with Fable implementing, debating & reviewing the code. It deals with auth & some security improvement so please read carefully and don't hesitate to reject and take the lead please. cc @abonneth

Purpose

Found during the security review of the hai login work: the CLI reads ./.env before the global key file, with no checks. hai run inside a cloned or forked repo that ships a .env with HAI_API_KEY sends the user's prompts, files and vault secrets to the attacker's organization, silently. Independent of the login changes.

What it does

• When the key comes from ./.env, every command prints once, on stderr (emitted from the shared state builder, so mcp install, local, login and --json modes are covered; Bugbot finding): "Using HAI_API_KEY from .env. Make sure this key is yours: a cloned or forked repo can ship a .env that carries someone else's key on purpose, and your runs would then land in their account." hai doctor carries the same sentence. The key value is never printed.
• A .env without HAI_ variables is ignored silently. A symlink in place of ./.env is rejected.
• The global file ~/.config/hai/.env must be a regular file owned by the current user with mode 600, as hai login writes it; otherwise it is ignored with a reason.
• Resolution order is unchanged: --api-key, HAI_API_KEY, ./.env, global file.

What it does not do

Detection, not prevention: a reader who skims stderr still sends the run to the attacker's org. Accepted for now.

Alternatives rejected

• Owner/mode check on ./.env: honest project files are created with the umask (0644) like planted ones, so it would reject most legitimate files and teach people to chmod past it.
• Trust-on-first-use prompt (direnv style, recorded under ~/.config/hai/trusted): built and tested, then dropped as too heavy for now. Candidate follow-up if the warning proves insufficient.
• Dropping ./.env support: per-project keys are a used feature.

Dependencies and merge order

None. Touches app.py near the client builder, so whichever hai login PR lands after it (#229 or #228) needs a small rebase.

🤖 Generated with Claude Code

---

Note

Medium Risk
Changes authentication credential resolution and global key file trust rules; misconfiguration could block legitimate keys until permissions are fixed, while project .env keys remain usable with only a stderr warning.

Overview
Hardens CLI credential loading and adds detection (not blocking) when HAI_API_KEY comes from a project .env, so runs in cloned repos with a planted key are less likely to go unnoticed.

Credential rules in credentials.py: only read env files that pass key_file_rejection (regular file; global ~/.config/hai/.env must be user-owned and mode 600). Project .env is used only if it sets at least one HAI_* variable; symlinks and unreadable/binary files are skipped without crashing. Ignored files surface via key_file_warnings().

User-facing behavior: _state() prints those warnings plus PROJECT_ENV_WARNING once per process on stderr (including --json). hai doctor repeats the project-key warning on success and fails login when keys are present but ignored. README documents the warning and global file permissions.

Resolution order is unchanged: --api-key → HAI_API_KEY → ./.env → global file.

^{Reviewed by Cursor Bugbot for commit b32c855. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cursor]

Stale Bugbot comment from a previous run.

[cursor]

Stale Bugbot comment from a previous run.

[cursor]

Stale Bugbot comment from a previous run.

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit b32c855. Configure here.}

[cursor]

Doctor misdiagnoses missing API key

Low Severity

When no key resolves, check_login treats any key_file_warnings line as the login failure and offers only owner/mode repair. A leftover .env symlink or directory then replaces the "no API key configured" guidance, and that fix text does not match symlink or non-file rejections.

 

^{Reviewed by Cursor Bugbot for commit b32c855. Configure here.}

[abonneth]

Thanks for digging into this. I think it guards the smaller risk though.

• A project .env can also set HAI_BASE_URL. The CLI then sends your real key from ~/.config/hai/.env to that host. That's key theft, much worse than someone planting their own key, and this PR doesn't cover it. If we guard one thing, I'd guard that: warn on (or refuse) a non-default base URL coming from ./.env.
• The 0600 + owner check silently ignores keys that work today: Docker mounts, k8s secrets, files written by hand. I'd warn instead of ignoring.
• Warning on every command for a legit per-project key will teach people to tune it out.
• _state() now prints. I'd keep it a plain getter.

~200 lines feels heavy for a heuristic. ~20 lines covering the base URL case plus one warning would get most of the value.

[H-maximedelpit]

Closing: since #233 the CLI resolves credentials from the argument, then HAI_API_KEY, then ~/.config/hai/.env, and never reads a project .env. Both risks this PR guarded (a planted key, or a base URL pointing your real key at another host, coming from a cloned repo's .env) went away with it. The base-URL angle was the right one to flag, thanks.