`gh issue list` and `gh pr list` fail with `malformed version: ` inside the agent sandbox under `tools.github.mode: gh-proxy` (Pi engine)

[sigh71]

Summary

With tools.github.mode: gh-proxy on the pi engine, gh issue list and gh pr list run by the agent inside the sandbox fail every time with:

malformed version: 
Command exited with code 1

gh api, gh issue view, gh pr view, gh pr diff and gh issue comment work through the same wrapper. The failure is independent of --repo: gh issue list --state open --label ... (no --repo) and gh pr list --repo owner/repo ... both fail, while gh issue view <n> --repo owner/repo succeeds in the same run.

This looks like the mechanism of #35264 (gh treats a non-github.com GH_HOST as GHES and runs a version check that github.com's /meta cannot satisfy, because that response has no installed_version), but in the cli-proxy sidecar rather than in user-defined steps. gh-aw-firewall's docs/gh-cli-proxy-design.md documents the sidecar executing gh with GH_HOST=localhost:18443. The #35264 fix changed proxyEnvVars() in the compiler, which does not reach the sidecar.

Why only list: those two subcommands run gh's GHES feature detection before their GraphQL query; view, api and comment do not, which matches what we observe.

Impact

Every schedule- or dispatch-triggered run has to discover its work by listing, so in our repository the bug-fix catch-up and the PR-iteration daily sweep silently nooped for days. The runs were green, the agent's final message was a noop saying no authorised issue could be identified, and nothing flagged it. Event-triggered runs were unaffected because the event carries the issue or PR number and the agent used gh issue view.

Versions

• gh-aw v0.87.10 (compiler); GH_AW_INFO_VERSION 0.84.3 in the run
• gh-aw-firewall (awf) v0.28.10
• engine: pi, models openai/gpt-5.6-terra and openai/gpt-5.6-sol
• Repository host: github.com (a private organisation repository, not GHES)

Reproduction

Any Pi workflow with tools.github.mode: gh-proxy and bash: true. In the agent's shell:

gh issue list --state open --limit 5
# → malformed version: 
#   Command exited with code 1
gh api 'repos/{owner}/{repo}/issues?state=open&per_page=5' --jq '.[].number'
# → works

Observed in four separate runs across two workflows over two days (2026-09-03/04), every list failing, every api/view succeeding. The runs are in a private repository, so I cannot link them; happy to share log excerpts on request.

Workaround

Tell agents to list through gh api 'repos/{owner}/{repo}/issues?...' and gh api 'repos/{owner}/{repo}/pulls?...'. A sidecar-side fix would presumably mirror #35264: set GH_HOST to the real identity host (github.com or the GHES host) and route through GITHUB_API_URL / GITHUB_GRAPHQL_URL instead.