[BUG] Cloud sessions: `gh` is not installed although the proxy already injects a GitHub credential; the GitHub MCP is the only supported path and is limited to session repos
Status Open
Maintainer reply None cached
Activity 0 comments · opened Sep 28, 2026
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
Environment
- Claude Code on the web (claude.ai/code), cloud container (Linux)
- GitHub access: repositories are attached to the session; the outbound proxy injects a GitHub PAT for
*.github.com - The session instructions given to the assistant state that the
ghCLI,huband direct GitHub API access are not available and that all GitHub interaction must go through themcp__github__*tools
Problem
The gh CLI is not installed in the container (command -v gh returns nothing). The credential for GitHub already exists in the environment, so this is not a missing-auth problem; the standard client is simply absent.
Consequences I ran into:
- Any workflow that is written around
ghcannot run as written. I gave the assistant a long instruction file for an autonomous multi-repository workflow. It requiresgh auth status,gh api ...,gh run list,gh pr mergeand several helper scripts that shell out togh. None of it runs; the assistant would have to re-implement each call through the MCP tools. - The MCP tools are scoped to the repositories attached to the session. For example, to read two public issues in another repository (anthropics/claude-code) the assistant could not use the GitHub MCP and had to fall back to a generic web fetch of the HTML page.
- Users cannot tell from the documentation which GitHub operations are supported through which path, so behavior looks arbitrary ("git clone works anonymously", "push is 403", "gh is missing", "MCP works only for attached repos").
Requested behavior
- Preinstall
ghin the cloud image and route it through the same proxy credential and the same repository scope as git and the GitHub MCP, so the security posture stays the same: what the session may write to is unchanged, but the standard tool works. gh auth statusshould reflect the real state (authenticated through the proxy, with the list of repositories in scope) instead of failing with "command not found".- If
ghis intentionally excluded, document that explicitly, together with the list of supported GitHub operations per path (git, MCP, proxy), so workflows and instruction files can be written for it.
Why it matters
Most existing automation, scripts and agent instruction files use gh as the GitHub client. Without it, they need a per-environment rewrite, and long autonomous tasks fail at the first gh call.
Related
- anthropics/claude-code#97966 (a single source of truth for repository permissions)
- anthropics/claude-code#97969 (Auto mode classifier denying an explicitly requested
add_repo)
Claude Model
Sonnet (default)
Is this a regression?
I don't know
Last Working Version
n/a
Claude Code Version
n/a
Platform
Other
Operating System
Other
Terminal/Shell
Other
Additional Information
_No response_