fix(cmd): include backslash in path detection for @ file references

[hsusul]

Observed Behavior

When passing an @ file reference containing backslash path separators (such as @subfolder\\unreadablefile or Windows paths without a file extension) that fails to open, embedFilesValue in pkg/cmd/flagoptions.go did not recognize \\ as a path separator. As a result, probablyFile / expectsFile evaluated to false, silently falling back to treating the unreadable file path as a raw string literal ("@subfolder\\\\unreadablefile") instead of surfacing a file read error.

Root Cause

probablyFile and expectsFile checks in pkg/cmd/flagoptions.go (lines 237 and 265) checked for . and / (strings.Contains(filename, ".") || strings.Contains(filename, "/")), but omitted \\ (strings.Contains(filename, "\\\\")).

Implementation

Updated path detection in embedFilesValue (pkg/cmd/flagoptions.go) to also check for \\ (strings.Contains(filename, "\\\\")), ensuring paths using backslashes are recognized as file references when handling unreadable file errors.

Regression Coverage

Added unit test case "non-existent file with backslash path @ prefix (error)" in pkg/cmd/flagoptions_test.go to assert that unreadable backslash path references properly return a file reading error instead of falling back to a raw string literal.

Exact Validation Commands & Results

• go test ./pkg/cmd -run TestEmbedFiles -> Passed
• go test ./internal/... -> Passed
• go vet ./internal/... ./pkg/... -> Passed (clean)
• git diff --check -> Passed (clean)

Limitations or Untested Platforms

None.

Unrelated Changes

No unrelated changes were included.

[jbeckwith-oai]

Reviewed the backslash path heuristic and both embedding modes; no blocking issues found. Focused TestEmbedFiles tests, go vet ./pkg/..., gofmt, and git diff --check passed. Full package tests require the repository mock server on localhost:4010, which was not running.

[markstuart-oai]

@codex review

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-09-15T18:01:50.437162Z	a691c9d	New commits
🔒 Security Review	✅ Completed 2026-09-15T18:04:53.678962Z	a691c9d	New commits

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. Can't wait for the next one!

Reviewed commit: efe9745fa2

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Security review completed. No security issues were found in this pull request.

Reviewed commit: efe9745fa2

View security finding report

Only the user who started this review can view the report in Codex.

ℹ️ About Codex security reviews in GitHub

This is an experimental Codex feature. Security reviews are triggered when:

• You comment "@codex security review"
• A regular code review gets triggered (for example, "@codex review" or when a PR is opened), and you’re opted in so security review runs alongside code review

Once complete, Codex will leave suggestions, or a comment if no findings are found.

[saioai]

i checked the updated branch. on macOS, \ is valid in a filename, but this change makes a missing @subfolder\missingfile error in both embedding modes. please make the backslash check Windows-only, test the macOS literal fallback and Windows error in both modes, then run CI on the fix.

[github-actions]

Castiron custom code

✅ No new custom-code files detected.

5 mixed files remain; 0 existing customizations changed.

Compared 25664bffc86a → b6ce984dfdaa. Generated baselines verified.

5 existing customizations unchanged

• pkg/cmd/adminorganizationcertificate.go
• pkg/cmd/cmd.go
• scripts/castiron/README.md
• scripts/castiron/custom_code_report.py
• scripts/castiron/test_custom_code_report.py

A changed generated baseline means this report cannot reliably identify which handwritten lines changed.

Inspect the custom-code diff

Download the exact patch produced by this run (requires repository access):

gh run download 35250673610 --repo openai/openai-cli \
  --name castiron-custom-code-35250673610-1 --dir /tmp/castiron-custom-code-35250673610-1
git apply --stat /tmp/castiron-custom-code-35250673610-1/custom-code.patch
cat /tmp/castiron-custom-code-35250673610-1/custom-code.patch

Or reproduce it from an SDK checkout containing the vendored reporter:

git fetch --no-tags origin 25664bffc86ac956e69b4f4fd9f96ec28baf93ca b6ce984dfdaa11f2ed9ade2ec5f3aa71ec509835
python3 scripts/castiron/custom_code_report.py report \
  --base 25664bffc86ac956e69b4f4fd9f96ec28baf93ca \
  --head b6ce984dfdaa11f2ed9ade2ec5f3aa71ec509835 --fetch --require-head-hash --public \
  --out /tmp/castiron-custom-code-b6ce984dfdaa
cat /tmp/castiron-custom-code-b6ce984dfdaa/custom-code.patch

This is the current full custom patch for mixed files, not an attribution of only the handwritten lines changed by this PR.

Full report and patch

[saioai]

approving. the backslash check is now windows-only, with tests for both embedding modes. this addresses my earlier concern about macOS literals.