Shell installer: literal $ in CODEX_INSTALL_DIR corrupts generated profile PATH

Aperta Adatta ai principianti
#60,494 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
72/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
shell
Ambito
cli

Direzione di ricerca

Il bug si trova in add_to_path() in scripts/install/install.sh, dove la riga PATH viene costruita a partire da BIN_DIR all'interno di una stringa tra virgolette doppie. Riproduci il problema con lo snippet autonomo presente nella issue, quindi modifica solo la parte letterale di BIN_DIR in modo che venga quotata per la shell, mantenendo l'espansione del $PATH esistente quando il profilo viene caricato. È completato quando una directory che contiene un simbolo di dollaro letterale permette di risolvere codex in una shell appena caricata con source, e la fixture di test copre questo caso.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

bug CLI
What issue are you seeing?

The standalone shell installer can complete successfully but leave Codex unavailable in a new shell when CODEX_INSTALL_DIR is an absolute path containing a literal dollar sign followed by variable-name characters.

The installed executable exists and is runnable by its full path. The generated shell-profile PATH entry reinterprets part of the literal directory name as an environment-variable expansion, so normal command lookup cannot find it.

Affected source: main 4dcd8df891ad38ed7d4ea59c44b817c293ffc0e2, also verified on 1885417cd45a8da5bfdeb7864a5380a7481d48f2.
Platform tested: Linux x86_64, /bin/sh. The full installer was also exercised with the repository's local download/package fixture, without network calls; the fixture reports package version 0.142.5 (not an assertion about the currently released Codex version).

What steps can reproduce the bug?

This minimal standalone reproduction exercises the exact PATH-line construction used in add_to_path(), followed by sourcing that line in a new POSIX shell. It makes no changes to your real home directory:

set -eu
root="$(mktemp -d)"
trap 'rm -rf "$root"' EXIT

# The dollar sign is literal and part of this absolute directory name.
BIN_DIR="$root/literal\$CODEX_TEST_UNSET/install-bin"
mkdir -p "$BIN_DIR"
printf '#!/bin/sh\necho codex-fixture\n' > "$BIN_DIR/codex"
chmod +x "$BIN_DIR/codex"

# The expression from scripts/install/install.sh:add_to_path().
path_line="export PATH=\"$BIN_DIR:\$PATH\""
printf '%s\n' "$path_line" > "$root/profile"
printf 'generated profile: '
cat "$root/profile"

# A new shell reads that generated profile without this variable set.
env -u CODEX_TEST_UNSET /bin/sh -c '
    . "$1"
    command -v codex || echo NOT_FOUND
    test -x "$2/codex" && echo ACTUAL_BINARY_EXISTS
' sh "$root/profile" "$BIN_DIR"

Actual output (temporary prefix abbreviated):

generated profile: export PATH="/tmp/.../literal$CODEX_TEST_UNSET/install-bin:$PATH"
NOT_FOUND
ACTUAL_BINARY_EXISTS

In a complete unchanged-installer fixture, an ordinary absolute install path succeeded and resolved from a fresh shell, while the same absolute path with literal $CODEX_TEST_UNSET installed successfully but failed fresh-shell lookup with exit 127. The original executable was present in both cases.

What is the expected behavior?

A generated profile entry should preserve CODEX_INSTALL_DIR exactly as a literal filesystem path. After installation and sourcing the supported profile, command -v codex should locate the installed binary regardless of literal dollar signs in the directory.

Additional information

Root cause: scripts/install/install.sh:add_to_path() constructs:

path_line="export PATH=\"$BIN_DIR:\$PATH\""

The installer substitutes BIN_DIR without escaping shell-significant characters inside a double-quoted assignment. This text is later written to the selected profile. When sourced, the shell expands the apparent variable inside what should have been the literal directory.

Suggested fix: POSIX-shell-quote the literal BIN_DIR component in the generated profile, while intentionally allowing the existing PATH to expand at source time. Test with a directory containing a dollar sign (and ideally quote/backslash characters), and assert that the newly sourced profile resolves the actual binary.

Related but distinct: #51538 covers relative CODEX_HOME/CODEX_INSTALL_DIR paths and cwd-dependent links. This bug uses an absolute path and is caused by shell interpolation within the generated profile. I searched issues/PRs for the literal-dollar/path-escaping case and did not find an existing equivalent report.

Limits: Confirmed on Linux /bin/sh; actual macOS shells and release downloads were not exercised. No claim of arbitrary command execution is made here; the demonstrated failure is incorrect PATH generation and inability to locate the installed command.

Lingua principale
Rust
Stelle
133k
Fork
21.1k
Merge medio
1m
PR unite (30g)
995

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di openai/codex

Tutte le issue di openai/codex

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.