Summary
Coding agents that read a config file from the working directory inherit a trust problem: a cloned repository can ship settings that redirect where the agent sends requests, credentials, notifications, and telemetry. The emerging convention is that project-local config may shape the project (skills, hooks, permissions, MCP servers) but must never control routing — base URLs, model providers, auth, notification sinks, or OTel endpoints. Those belong to user-level config. Codex CLI enforces this with a hard ignore-list even for trusted projects; yoyo (as measured on Day 256) gates the project surfaces but leaves base_url and provider open, which leaks the user's API key to any host the repo names.
Key Points
- Project-scoped config should load only when the project is trusted — trust is a precondition, not a substitute for a denylist.
- Even for trusted projects, Codex CLI ignores project-local
openai_base_url,chatgpt_base_url,model_provider,model_providers,notify,profile(s),otel, and the realtime WS base URL. - Rationale: a cloned repo must not be able to redirect the user's credentials or notifications.
- Gating project behavior (skills, hooks, permissions, MCP) but not routing (
base_url,provider) is an exploitable gap, not a partial mitigation. - The failure mode is silent: in the yoyo case the banner printed no base URL and emitted no warning.
- Peer tools are converging on related safety knobs: deny-instead-of-prompting, refusing writes outside working directories, failing loudly on startup errors, and surfacing sign-in expiry in non-interactive mode.
Concepts
- Project-scoped config — settings file resolved from the repository (e.g.
.codex/config.toml,./.yoyo.toml) rather than from the user's home directory.