A malicious `<workspace>/.deepseek/config.toml` could escalate
privileges via the per-project overlay shipped in #485:
* `api_key` / `base_url` / `provider` — exfiltrate prompts to
an attacker-controlled endpoint by swapping the user's
credentials and target host.
* `mcp_config_path` — point the MCP loader at a config that
spawns arbitrary stdio servers under the user's identity.
Adds a `DENY_AT_PROJECT_SCOPE` allowlist-by-omission to
`merge_project_config`. The four credential / redirect keys
are silently dropped from the overlay; a stderr warning fires
when one is present so a user who *did* expect the override
sees the deny instead of a silent discard:
warning: project-scope config key `api_key` is ignored —
set it in `~/.deepseek/config.toml` instead.
The remaining override surface (model, approval_policy,
sandbox_mode, notes_path, reasoning_effort, max_subagents,
allow_shell, instructions array) is unchanged. Note that this
slice does NOT yet block escalation via value comparison — a
project setting `approval_policy = "auto"` still wins over a
user's stricter `"never"`. That richer check is filed as a
v0.8.9 follow-up.
Tests:
* `project_overlay_overrides_model_but_denies_provider`
replaces the previous test that asserted provider WOULD
override (now reversed).
* New `project_overlay_denies_dangerous_credentials_and_redirects`
models the attacker scenario directly: project sets all four
denied keys, asserts the user's pre-existing values survive
and the project's are discarded.
CHANGELOG documents the deny-list rationale and lists which
fields remain overridable.
Hunter Bown
926ffcb4f4