Codex PR integration fails in WSL with gh: Expected VAR_SIGN, actual: COLON

Same problem. Feedback ID: no-active-thread-019f5c77-1208-7c20-ac00-430264da0fd4

Same

<img width="922" height="608" alt="Image" src="https://github.com/user-attachments/assets/21ebf451-5b0f-414f-a70d-d24c8e59a5c0" />

Independent reproduction on the Windows Codex app:

• Codex app version: 26.707.9981.0
• Environment: WSL2 Ubuntu
• GitHub CLI: gh 2.46.0
• Trigger: the app-wide Pull Requests page, not a repository-specific review pane
• UI displays twice:

gh: Expected VAR_SIGN, actual: COLON (":") at [2, 9]

I inspected the installed app bundle. The gh-pr-search implementation contains a syntactically valid multiline GraphQL declaration beginning with:

query($searchQuery: String!, $first: Int!, $after: String) {

It passes that query to gh api graphql as an argument. The reported location is significant: if the three $... variable names are removed during shell expansion, line 2 begins as:

query(: String!, : Int!, : String) {

The first colon is then exactly at line 2, column 9, matching the error. Desktop logs also show the request source as pull_requests_page / gh-pr-search and the processes being spawned inside WSL.

This adds evidence that the WSL process bridge is not preserving literal $ characters in the multiline GraphQL argument. No repository contents or credentials were included in this report.

Same problem here

I'm facing the same issue and wanted to provide additional independent reproduction with current versions:

Environment

• Codex Desktop: 26.715.4045.0
• Execution location: WSL2
• WSL kernel: 6.6.87.2-microsoft-standard-WSL2
• Distribution: Ubuntu 24.04.4 LTS
• GitHub CLI: gh 2.96.0 (2026-07-02)

Observed behavior

The app-wide Pull Requests tab fails with:

gh: Expected VAR_SIGN, actual: COLON (":") at [2, 9]

Control checks

Authentication succeeds with gh auth status. I also ran the following manually in the same WSL environment:

gh search prs --author @me --state open --limit 5 --json url --jq 'length'
# => 2

gh pr list --repo XXX --state open --limit 20 --json number --jq 'length'
# => 1

gh api graphql \
  -f 'query=query($login:String!){ user(login:$login){ login } }' \
  -F login=willyyr \
  --jq '.data.user.login'
# => willyyr

GitHub authentication, global PR search, repository-scoped PR listing, and GraphQL variables therefore work when invoked directly. This also reproduces on gh 2.96.0, so updating the CLI does not resolve the app integration failure.

The exact parser position remains consistent with the app’s multiline query losing its variable names before it reaches GitHub—for example, query($searchQuery: String!, ...) becoming query(: String!, ...).

It may help to capture the arguments/query immediately before the WSL spawn and again at the gh process boundary, and to pass the query without an interpolating shell—or via standard input—so literal $ characters are preserved.

Same issue here

O mesmo acontece.

Same issue here

Same issue here

Same issue here

same issue here

same issue here

Reproduced on the Windows Codex Desktop app with WSL2.

Both environments are authenticated and working independently:

• In Windows PowerShell, gh resolves to C:\Program Files\GitHub CLI\gh.exe.
• gh api user --jq .login returns salty919.
• In WSL, gh auth status is valid and manual GraphQL requests succeed.

Despite that, Codex's Pull Request integration still fails with:

gh: Expected VAR_SIGN, actual: COLON (":") at [2, 9]

This is not an authentication or user-setup problem. I was repeatedly directed through OAuth, keyring, and Windows/WSL setup even though authentication was already valid, and the integration remained broken.

For a paid OpenAI service, this is unacceptable. The current experience feels amateurish and the troubleshooting flow wastes the user's time by treating a product defect as an authentication problem. Please fix the Windows/WSL Pull Request integration, clearly acknowledge the product bug, and provide a concrete workaround or status update instead of sending users through repeated re-authentication.

@salty919 Who was directing you through repeated re-authentication? What troubleshooting flow?
Everybody here who took the time to analyse the problem further already came to conclusion its a relatively simple parsing bug that leads to this syntax error. Something the error itself already hints at, of course.

Same issue here.

I reproduced this against Codex Desktop 26.803.5235.0 on Windows 11 + WSL2 (Ubuntu-26.04) and isolated the exact argument-boundary failure.

The installed Desktop bundle builds WSL process arguments in this shape:

[
  "-d", distro,
  "--cd", cwd ?? ".",
  "--",
  "/usr/bin/bash", "-lc", command,
]

The PR search query in the same bundle starts with:

query($searchQuery: String!, $first: Int!, $after: String) {

I replayed the exact boundary with Windows Node child_process.spawnSync, rather than invoking gh from an interactive WSL shell:

• With wsl.exe ... -- ..., a direct Python argv probe receives query(: String!) from an input argument of query($searchQuery: String!).
• Single-quoting the query inside the nested bash -lc command does not prevent the loss at this outer WSL boundary.
• With only the WSL separator changed from -- to --exec, Python receives the literal $searchQuery unchanged.
• A complete gh api graphql replay using the app's multiline query fails with Expected VAR_SIGN, actual: COLON (\":\") at [2, 9] under --, and succeeds with valid JSON under --exec.

So this is not a gh authentication, GitHub API, repository, or GraphQL construction problem. The GraphQL argument is mutated while Codex Desktop forwards the command through wsl.exe.

The minimal fix for this failure is:

- "--",
+ "--exec",

in the Windows-to-WSL argument builder. Both direct command execution and the existing nested /usr/bin/bash -lc <command> form preserve the GraphQL variables with --exec.

The same WSL argument builder also defaults a missing cwd to .; that is the separate Git is unavailable failure tracked in #35119. Fixing both --exec forwarding and the invalid relative --cd . fallback would address the two regressions at their shared boundary.