[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 gh CLI, hub and direct GitHub API access are not available and that all GitHub interaction must go through the mcp__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:

  1. Any workflow that is written around gh cannot run as written. I gave the assistant a long instruction file for an autonomous multi-repository workflow. It requires gh auth status, gh api ..., gh run list, gh pr merge and several helper scripts that shell out to gh. None of it runs; the assistant would have to re-implement each call through the MCP tools.
  2. 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.
  3. 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 gh in 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 status should reflect the real state (authenticated through the proxy, with the list of repositories in scope) instead of failing with "command not found".
  • If gh is 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_

View original on GitHub ↗