Symlinked .rules files in ~/.codex/rules are silently ignored

What version of Codex CLI is running?

codex-cli 0.144.1

What subscription do you have?

ChatGPT Pro

Which model were you using?

gpt-5.5

What platform is your computer?

Darwin 25.5.0 arm64 arm

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

Ghostty 1.3.1 (TERM=xterm-ghostty), no tmux, no zellij.

Codex doctor report

{
  "schemaVersion": 1,
  "overallStatus": "fail",
  "codexVersion": "0.144.1",
  "relevantChecks": {
    "config.load": {
      "status": "ok",
      "summary": "config loaded",
      "details": {
        "CODEX_HOME": "/Users/user/.codex",
        "config.toml": "/Users/user/.codex/config.toml",
        "config.toml parse": "ok",
        "cwd": "/Users/user/Code/dotfiles",
        "model": "gpt-5.5",
        "model provider": "openai"
      }
    },
    "sandbox.helpers": {
      "status": "ok",
      "summary": "sandbox configuration is readable",
      "details": {
        "approval policy": "OnRequest",
        "filesystem sandbox": "restricted",
        "network sandbox": "restricted"
      }
    },
    "runtime.provenance": {
      "status": "ok",
      "summary": "running brew on macos-aarch64",
      "details": {
        "install method": "brew",
        "platform": "macos-aarch64",
        "version": "0.144.1"
      }
    }
  },
  "note": "The full doctor output also reported unrelated local state DB warnings and provider reachability failures from the same restricted network context. This report is specifically about symlinked .rules files being skipped by the execpolicy loader."
}

What issue are you seeing?

Symlinked .rules files inside ~/.codex/rules are not loaded.

This breaks dotfiles / Stow-style setups where ~/.codex/rules is a real directory and individual .rules files inside it are symlinks to tracked files in a dotfiles repository. Codex starts normally, but the rule files are silently skipped, so configured prefix_rule(...) entries do not apply.

It also makes it harder to use standard dotfiles synchronization tools such as GNU Stow, where the common setup is to manage individual files as symlinks from the home directory into a tracked dotfiles repository.

What steps can reproduce the bug?

Create a real rules directory:

mkdir -p ~/.codex/rules

Put a rule file somewhere else:

mkdir -p ~/dotfiles/codex-rules
cat > ~/dotfiles/codex-rules/default.rules <<'RULES'
prefix_rule(
    pattern = ["gh", "issue", "list"],
    decision = "allow",
    justification = "Allow listing GitHub issues.",
)
RULES

Symlink that file into ~/.codex/rules:

ln -s ~/dotfiles/codex-rules/default.rules ~/.codex/rules/default.rules

Start Codex and run:

gh issue list --repo openai/codex

Actual result: the command behaves as if the rule was not loaded.

If ~/.codex/rules itself is symlinked to the tracked rules directory, the rule is loaded:

rm -rf ~/.codex/rules
ln -s ~/dotfiles/codex-rules ~/.codex/rules

What is the expected behavior?

Codex should load .rules files that are symlinks to regular files, or report a clear warning that symlinked rule files are ignored.

Additional information

The behavior appears to come from collect_policy_files() in codex-rs/core/src/exec_policy.rs.

It scans the rules directory with read_dir, checks the .rules extension, and only adds entries where entry.file_type().is_file() is true. Symlinked .rules entries do not pass that filter, so they are skipped without a warning.

I can open a PR for this if maintainers want an external patch.