Back to Signal Feed
CodeTracked since May 19, 2026

Aider OAuth now writes OpenRouter token with owner-only permissions

This PR changes the OpenRouter OAuth credential persistence path in `aider/onboarding.py` so `~/.aider/oauth-keys.env` and its parent directory are hardened to owner-only permissions, eliminating reliance on default `open()`+umask behavior that could leave secrets world-readable.

aider/onboarding.pyOPENROUTER_API_KEY~/.aider/oauth-keys.envumask

What Happened

  • This PR changes the OpenRouter OAuth credential persistence path in `aider/onboarding.py` so `~/.aider/oauth-keys.env` and its parent directory are hardened to owner-only permissions, eliminating reliance on default `open()`+umask behavior that could leave secrets world-readable.
  • This PR changes the OpenRouter OAuth credential persistence path in `aider/onboarding.py` so `~/.aider/oauth-keys.env` and its parent directory are hardened to owner-only permissions, eliminating reliance on default `open()`+umask behavior that could leave secrets world-readable.
  • 1 evidence item attached for review.

What is Different

Before

Scattered source updates, isolated context, and manual follow-up across multiple feeds.

Now

Introduces explicit credential hardening in the OAuth save flow: it forces `~/.aider` to `0o700`, creates a new token file with `os.open(..., O_WRONLY|O_CREAT|O_TRUNC, 0o600)` wrapped by `os.fdopen`, and applies `os.chmod(key_file, 0o600)` even on re-runs so existing files are corrected from permissive modes.

Why Track This

Why It Matters

Users and operators sharing a Linux/macOS host or mounted home directory are less likely to have their OpenRouter API key silently read by other local accounts, reducing the practical risk of quota theft and unauthorized API calls under the victim's identity. The implementation closes the default-umask permission gap by enforcing `0o700` on `~/.aider` and `0o600` on `oauth-keys.env`, and by avoiding the previous TOCTOU window when a file could briefly be created with broader permissions; continue watching for any deployments where chmod is ineffective (for example, restrictive filesystem mounts or legacy non-Unix behavior) and whether preexisting `~/.aider` permission drift is cleaned up during upgrades.

Impact

Users and operators sharing a Linux/macOS host or mounted home directory are less likely to have their OpenRouter API key silently read by other local accounts, reducing the practical risk of quota theft and unauthorized API calls under the victim's identity. The implementation closes the default-umask permission gap by enforcing `0o700` on `~/.aider` and `0o600` on `oauth-keys.env`, and by avoiding the previous TOCTOU window when a file could briefly be created with broader permissions; continue watching for any deployments where chmod is ineffective (for example, restrictive filesystem mounts or legacy non-Unix behavior) and whether preexisting `~/.aider` permission drift is cleaned up during upgrades.

What To Watch Next

  • Watch whether aider/onboarding.py becomes a repeated pattern.
  • Track follow-up changes around AI Security.
  • Compare future signals against this evidence trail.
  • Re-check risk flags: preexisting_config_dir_permissions_not_tightened, non_unix_chmod_noop_behavior.
Open Topic TimelineOpen Technical EventOpen Original Sourcepreexisting_config_dir_permissions_not_tightened / non_unix_chmod_noop_behavior / legacy_world_readable_token_files_from_previous_installs

Supporting Evidence

GITHUB PULL REQUESTHigh Trust

aider-ai/aider PR #5154: onboarding: write ~/.aider/oauth-keys.env at 0o600 instead of default umask (0o644)

The previous flow used plain `open(path, "a")`, which on common `umask 022` hosts created `~/.aider/oauth-keys.env` with mode `0o644`, exposing `OPENROUTER_API_KEY` to other local users.