Git Can Push, but Claude Code Can't Read GitHub Issues: SSH vs GitHub API Permissions

In October 2026 I set up Claude Code on an Oracle server. The GitHub SSH key was in place, and git fetch and git push both worked. But when I asked Claude Code to read a GitHub Issue, it reported missing GitHub API authentication: the server had no gh CLI, and no GH_TOKEN or GITHUB_TOKEN.

The short version: an SSH key only authorizes Git transfers. For Claude Code to read GitHub Issues and PRs, it needs separate GitHub API authentication. The most direct fix is to install the GitHub CLI (gh) on the server, sign in as the Linux user that actually runs Claude Code, and confirm with gh auth status and gh issue list. Before signing in, decide how much access to grant and where the token will be stored.

This is my setup log from October 2026 on an Ubuntu 24.04 server. project-a and ORG/REPO in the commands are examples; replace them with your own user and a repo you have access to. For GitHub CLI flags and behavior, go by the official manual at cli.github.com (checked 12 October 2026).

Why Claude Code can’t read GitHub Issues: SSH and the API are separate permissions

GitHub has two different ways to access it:

The SSH key lets Git exchange commits with GitHub, but Issues, PRs and comments go through the GitHub API. To read an Issue, Claude Code usually uses gh or calls the API with a token. Without either, it can’t read Issues, even if git push works perfectly.

Install gh and sign in as the Linux user that runs Claude Code

Install the GitHub CLI

Install it from the admin account:

sudo apt update && sudo apt install -y gh
gh --version

For installation methods and versions, go by the official GitHub CLI installation guide.

Run gh auth login as the right user

Sign in as the Linux user that actually runs Claude Code. If Claude Code runs as the user project-a, signing in to gh from the admin account does nothing for it.

sudo -iu project-a

gh auth login --hostname github.com --git-protocol ssh --web --skip-ssh-key

(Official gh auth login manual)

Confirm the sign-in worked and Issues are readable

gh auth status
gh issue list --repo ORG/REPO --limit 5
gh issue view 70 --repo ORG/REPO

gh auth status shows the signed-in account and where the token is stored (official manual). If it can list Issues, Claude Code running as the same user can read them with gh too.

Where the token lives: watch out on a Linux server without a desktop

According to the official GitHub CLI manual, gh stores the token in the system credential store by default; if it can’t find a credential store or can’t use one, it writes the token to a plain-text file instead. On a Linux server without a desktop environment, that is quite likely what happens.

So do a few things:

• Use gh auth status to check where the token is stored.
• Lock down the file permissions on ~/.config/gh/ so only this Linux user can read it.
• Give different projects, and work with different levels of trust, to different Linux users, so one user’s token can’t be read by other projects.
• Don’t run gh auth token or gh auth status --show-token just to paste logs; the output shows the token in plain view.
• Don’t upload ~/.config/gh/ or ~/.ssh/ anywhere public, and don’t put them in a repo.

How much access to grant: least-privilege options

gh auth login uses your personal GitHub account’s authorization, which may cover more than a single repo needs. If this server only needs to read and write Issues and PRs for one repo, consider a narrower option:

The official GitHub CLI manual notes that passing a fine-grained token with --with-token can lead to confusing behavior, and recommends the GH_TOKEN environment variable instead. Whichever option you use, never put the token in the repo, CLAUDE.md, systemd unit files, articles or screenshots, and don’t paste it into a chat to ask someone for help.

Check this too when using –spawn=worktree

If Claude Code Remote Control runs in --spawn=worktree mode, each new session works in its own Git worktree. The worktree changes the directory but not the Linux user, so the gh sign-in still applies. It’s still worth checking before you start:

• The session is running as the Linux user you expect.
• gh is on the PATH (when started by systemd, PATH is set in the unit file).
• This user’s authorization can read the target repo.

For how to split work across multiple Remote Controls and worktrees, see Running Multiple Claude Code Remote Controls on One Server.

From Issue to PR: connecting the tasks

Once gh works, GitHub Issues can serve as a task list for Claude Code: write clearly in the Issue what needs doing, Claude Code reads the Issue, makes changes on a branch and opens a PR, and you review the PR.

# Read only, don't modify Issues
gh issue list --repo ORG/REPO --state open --limit 20
gh issue view 70 --repo ORG/REPO --comments

# Check PR and CI status
gh pr list --repo ORG/REPO
gh pr checks 123 --repo ORG/REPO

A few things to watch:

• A commit on a feature branch is not the same as being live. Confirm the PR is merged, CI has passed and the deployment is done.
• Before opening a PR, check the current branch, the base branch and the diff; a --spawn=worktree session may not be on the branch you think it is.
• Reading Issues and changing Issues are different permissions. If read access is all you need, grant only read.

For the full server and Remote Control setup, see Running Claude Code Remote Control on a Free Oracle Cloud Server. For how the whole site uses GitHub to manage posts and deployments, see Jason Finance from Zero to One.

FAQ

Why does git push work while Claude Code can't read GitHub Issues?

Because they use different permission mechanisms. An SSH key only authorizes Git transfers such as git fetch and git push. Issues and PRs are read through the GitHub API, which needs a GitHub CLI sign-in or an API token. Having an SSH key set up does not mean the API works too.

How do I let Claude Code read GitHub Issues?

Install gh on the server, switch to the Linux user that actually runs Claude Code, run gh auth login --hostname github.com --git-protocol ssh --web --skip-ssh-key to authorize, then confirm with gh auth status and gh issue list.

What does --skip-ssh-key do in gh auth login?

When SSH is the Git protocol, gh looks for keys and asks whether to generate and upload a new SSH key. If the server already has a working GitHub SSH key, adding --skip-ssh-key skips that step.

Where does gh store its token, and is it safe?

By default gh stores it in the system credential store; if it can't find one or can't use it, it falls back to a plain-text file. On a Linux server without a desktop environment, pay particular attention to file permissions. gh auth status shows where the token is stored.

Does signing in to gh with a personal account grant too much access?

It can. The personal authorization from gh auth login may cover more than a single repo needs. For least privilege, consider a fine-grained token or a GitHub App limited to specific repos and to Issues and PR permissions.

Can I put a GitHub token in CLAUDE.md or a systemd config?

No. A token should never appear in the repo, CLAUDE.md, systemd unit files, shell history, logs or public screenshots. Also don't run gh auth token or gh auth status --show-token just to paste logs.