›_ Codex Issues
Codex Issues / #9286

Git push --dry-run fails with Bad owner or permissions on /etc/ssh/ssh_config.d/... (SSH config owned by nobody inside sandbox)

Open 💬 5 comments Opened Jan 15, 2026 by vadimcomanescu

What version of Codex is running?

codex-cli 0.84.0

What subscription do you have?

Pro

Which model were you using?

5.2-high (happens on all)

What platform is your computer?

Linux 6.18.3-arch1-1 x86_64

What terminal emulator and version are you using (if applicable)?

Ghostty

What issue are you seeing?

Trying to do a git push dry run from within Codex fails before auth/networking, because OpenSSH refuses to read system SSH config due to ownership/permissions.

Command:

git push --dry-run

Output:

Bad owner or permissions on /etc/ssh/ssh_config.d/20-systemd-ssh-proxy.conf
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

Also reproducible directly via ssh config parsing:

ssh -G github.com

Output:

Bad owner or permissions on /etc/ssh/ssh_config.d/20-systemd-ssh-proxy.conf

Key observation: inside this Codex environment, /etc/ssh and its config files are owned by nobody (uid 65534), which triggers OpenSSH’s safety checks.

Evidence:

whoami && id

root
uid=0(root) gid=0(root) groups=0(root),65534(nobody)

ls -ld /etc/ssh /etc/ssh/ssh_config.d

drwxr-xr-x 1 nobody nobody 344 Nov 27 19:09 /etc/ssh
drwxr-xr-x 1 nobody nobody 50 Jan 9 11:42 /etc/ssh/ssh_config.d

ls -l /etc/ssh/ssh_config.d/20-systemd-ssh-proxy.conf

lrwxrwxrwx 1 nobody nobody 63 Jan 6 18:29 /etc/ssh/ssh_config.d/20-systemd-ssh-proxy.conf -> ../../../usr/lib/systemd/ssh_config.d/20-systemd-ssh-proxy.conf

ls -l /usr/lib/systemd/ssh_config.d/20-systemd-ssh-proxy.conf

-rw-r--r-- 1 nobody nobody 807 Jan 6 18:29 /usr/lib/systemd/ssh_config.d/20-systemd-ssh-proxy.conf

What steps can reproduce the bug?

  1. Start Codex CLI session in a git repo with an SSH remote (example above).
  2. Run git push --dry-run.
  3. Observe failure: Bad owner or permissions on /etc/ssh/ssh_config.d/20-systemd-ssh-proxy.conf.
  4. Confirm /etc/ssh and /usr/lib/systemd/ssh_config.d/... are owned by nobody inside the Codex environment (commands above).

Notes:

  • This appears to be an environment/sandbox regression: OpenSSH rejects system config because it is not owned by root (even though the process user is root).
  • In the same session, codex --version prints a PATH-update warning (permission denied) which may be related.

What is the expected behavior?

  • git push --dry-run should either:
  • proceed to network/auth and succeed, or
  • fail with an expected SSH auth error (e.g., missing key), or
  • fail with a normal git remote/access error,
  • but not fail immediately due to broken ownership of system SSH config files inside the Codex environment. Previous version worked perfectly.

Additional information

Codex sandbox/config observed in this session (from harness):

  • sandbox_mode: workspace-write
  • approval_policy: on-failure
  • Network access: enabled

Tool versions:

  • git --version: git version 2.52.0
  • ssh -V: OpenSSH_10.2p1, OpenSSL 3.6.0 1 Oct 2025

View original on GitHub ↗

5 Comments

geldot · 5 months ago

As an additional data point, the Cursor IDE (no Codex involved) issues the exact same Bad owner or permissions on /etc/ssh/ssh_config.d/20-systemd-ssh-proxy.conf error. The commonality is that this is an Arch Linux system too.

I don't know if Cursor and Codex are using the same underlying sandbox library or sandbox approach that's missing special case handling for permissions checks in recent OpenSSH versions or something else entirely.

As a workaround, I've found that scp/ssh -F /dev/null avoids the system config file and things work, at least in Cursor but will probably work in Codex too.

hontvari · 2 months ago

If the ssh_config.d contains real configuration, then the only workaround is to completely switch off the sandbox.

Otherwise codex cannot use ssh.

The bug here is that the sandbox arbitrarily shows different file owner and file group, for no useful reason. At least I do not know of any valid reason.

As chatgpt recommends: Please add a "please_do_not_lie_about_ssh_config_ownership" flag to the configuration.

sebastianelsner · 28 days ago

Still reproducible with:

  • Codex CLI 0.146.0
  • AlmaLinux 9.6
  • OpenSSH_8.7p1-45.el9
  • A managed workspace permission profile with filesystem restrictions and network access enabled

The failure occurs before authentication or networking:

$ ssh -G <host>
Bad owner or permissions on /etc/ssh/ssh_config.d/04-ipa.conf

$ git pull --ff-only
Bad owner or permissions on /etc/ssh/ssh_config.d/04-ipa.conf
fatal: Could not read from remote repository.

RPM metadata says the affected OpenSSH files should be root:root, but inside the Codex Bubblewrap sandbox they appear as nobody:nobody:

$ stat -c '%u:%g %U:%G %n' /etc/ssh/ssh_config.d/04-ipa.conf
65534:65534 nobody:nobody /etc/ssh/ssh_config.d/04-ipa.conf

This is not isolated to that file: other package-owned system files and executables also appear as nobody:nobody in the sandbox.

Control test:

$ GIT_SSH_COMMAND='ssh -F /dev/null' git pull --ff-only
Already up to date.

That confirms workspace Git metadata is writable and network/SSH-agent access works. However, -F /dev/null is not an acceptable general workaround here because the system SSH configuration contains IPA known-host handling and the Red Hat system crypto policy.

I also tested the documented legacy Landlock fallback with this managed permission profile. Codex aborts with:

permission profiles requiring direct runtime enforcement are incompatible with --use-legacy-landlock

So neither the empty-config workaround nor Landlock is viable for an enterprise-managed environment.

It would be helpful if the Bubblewrap sandbox preserved trustworthy ownership for the read-only system tree, or otherwise supported OpenSSH system Include files. A codex doctor check for this condition would also make the failure much easier to diagnose.

vitorpy · 27 days ago

Still reproducible on a current Arch Linux setup:

  • Codex CLI 0.146.0
  • Linux 7.1.5-arch1-2 x86_64
  • OpenSSH_10.4p1 / OpenSSL 3.6.3
  • managed workspace-write permission profile with a restricted filesystem

The affected systemd-provided SSH include is correctly owned on the host:

$ stat -c '%u:%g %a %N' /etc/ssh/ssh_config.d/20-systemd-ssh-proxy.conf
0:0 777 '/etc/ssh/ssh_config.d/20-systemd-ssh-proxy.conf' -> '../../../usr/lib/systemd/ssh_config.d/20-systemd-ssh-proxy.conf'

$ stat -L -c '%u:%g %a %N' /etc/ssh/ssh_config.d/20-systemd-ssh-proxy.conf
0:0 644 '/etc/ssh/ssh_config.d/20-systemd-ssh-proxy.conf'

Every parent directory is also root-owned and not group/world-writable. In host context, the normal configuration parses and the configured host alias works:

$ ssh -G mediaserver
host mediaserver
hostname <LAN IP>
user vitorpy
...

$ ssh mediaserver uname -n
mediaserver

Inside the Codex sandbox, the same symlink, target, and all parent path components are exposed as UID/GID 65534 (nobody:nobody):

$ stat -c '%u:%g %a %N' /etc/ssh/ssh_config.d/20-systemd-ssh-proxy.conf
65534:65534 777 '/etc/ssh/ssh_config.d/20-systemd-ssh-proxy.conf' -> '../../../usr/lib/systemd/ssh_config.d/20-systemd-ssh-proxy.conf'

$ stat -L -c '%u:%g %a %N' /etc/ssh/ssh_config.d/20-systemd-ssh-proxy.conf
65534:65534 644 '/etc/ssh/ssh_config.d/20-systemd-ssh-proxy.conf'

$ ssh -G mediaserver
Bad owner or permissions on /etc/ssh/ssh_config.d/20-systemd-ssh-proxy.conf

This confirms the failure is caused solely by the sandbox ownership remapping of a trustworthy read-only system tree; the host permissions are valid.

Using ssh -F none avoids the ownership check, but is not an equivalent workaround: it also discards the legitimate system/user SSH configuration, including the mediaserver host alias, so the hostname then fails to resolve.

jwilger · 15 days ago

Additional Linux / user SSH-config data point

This also affects a user-level ~/.ssh/config, not only /etc/ssh includes. The host configuration is valid; the failure is introduced by the sandbox view of that file.

Environment

  • Codex CLI: 0.147.0
  • OS: NixOS 26.11.20260802.6438090
  • Kernel: Linux 7.1.5 x86_64
  • OpenSSH: OpenSSH_10.3p1
  • Git: 2.54.0
  • Shell: zsh
  • Sandbox: workspace-write with the SSH config mounted read-only

~/.ssh/config is Home Manager-managed and resolves into the Nix store. That is safe on the host and normal OpenSSH configuration parsing succeeds.

Host control

$ stat -Lc '%u:%g %a %U:%G %n' ~/.ssh/config
0:0 444 root:root /home/jwilger/.ssh/config

$ ssh -G github.com >/dev/null && echo host_ssh_config_parse=ok
host_ssh_config_parse=ok

Inside the Codex sandbox

$ stat -Lc '%u:%g %a %U:%G %n' ~/.ssh/config
65534:65534 444 nobody:nogroup /home/jwilger/.ssh/config

$ ssh -G github.com >/dev/null
Bad owner or permissions on /home/jwilger/.ssh/config

The file remains read-only, but its owner/group are remapped from root:root to nobody:nogroup. OpenSSH rejects that metadata before authentication or network access. The same SSH/Git operation succeeds when Git runs outside the Codex sandbox, which isolates the failure to sandbox mount/identity presentation.

Expected behavior

A trusted host SSH configuration exposed read-only inside the sandbox should retain OpenSSH-safe ownership metadata. This is not a request to weaken OpenSSH checks, disable commit signing, or broaden filesystem access.

ssh -F /dev/null can mask the symptom, but it is not an adequate workaround: it discards legitimate user SSH configuration, host aliases, signing settings, policy includes, and known-host behavior. This appears to be the same underlying metadata-preservation class as the system-config failure in this issue.