›_ Claude Code Issues
Claude Code Issues / #44805

Remote Control: mobile app fails with "GitHub repository access check failed" when environment has git_repo_url

Open 💬 17 comments Opened Apr 7, 2026 by liby

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?

Running claude remote-control in a git repository directory registers the environment successfully (HTTP 200), but the Claude iOS app fails to send messages with:

Failed to send message — GitHub repository access check failed — re-authorize GitHub in settings

Running claude remote-control in a non-git directory works without issues — the session connects, --name takes effect, and mobile can send messages normally.

What Should Happen?

Remote Control sessions execute locally — the mobile app should not require GitHub repository access for Remote Control environments.

Steps to Reproduce

  1. cd into a directory that is a git repository with a GitHub remote
  2. Run claude remote-control --name "test" --debug-file /tmp/rc-debug.log
  3. Environment registers successfully (200)
  4. Open Claude iOS app → Code tab → select the environment
  5. Send any message
  6. Error: "GitHub repository access check failed — re-authorize GitHub in settings"

Contrast:

  1. cd into a directory that is NOT a git repository
  2. Run claude remote-control --name "test"
  3. Open Claude iOS app → same flow
  4. Works correctly — session connects, --name is displayed, messages can be sent

Observed Behavior

The environment registration request includes git_repo_url:

{
  "machine_name": "<hostname>",
  "directory": "/path/to/project",
  "branch": "master",
  "git_repo_url": "git@github.com:example/example-repo.git",
  "max_sessions": 32,
  "metadata": {"worker_type": "claude_code"}
}

When git_repo_url is present, the mobile app performs a GitHub repository access check. When it is absent (non-git directory), no check is performed and Remote Control works.

Additionally, session creation via POST /v1/sessions fails with:

Session creation failed with status 400: source: Extra inputs are not permitted

This causes --name to silently not take effect (the session is never created, so the title is lost). This 400 error may be related to #42507.

Error Messages/Logs

Debug log (git directory):

[bridge:init] bridgeId=<uuid> dir=/path/to/project branch=master gitRepoUrl=git@github.com:example/example-repo.git machine=<hostname>
[bridge:api] POST /v1/environments/bridge -> 200 environment_id=env_<id>
[bridge] Session creation failed with status 400: source: Extra inputs are not permitted

Mobile app error:

Failed to send message — GitHub repository access check failed — re-authorize GitHub in settings

Non-git directory (working):

·✔︎· Connected · GitHub · HEAD
    Capacity: 2/32 · New sessions will be created in the current directory
    demo

Claude Model

Opus 4.6

Is this a regression?

Unknown — first time using Remote Control on this account.

Claude Code Version

2.1.92

Platform

claude.ai

Operating System

macOS (Darwin 25.4.0, arm64)

Terminal/Shell

zsh

Additional Information

  • Plan: Max
  • Auth: claude.ai OAuth
  • tengu_ccr_bridge: true
  • iOS app version: latest
  • Related: #42507 (same 400 "Extra inputs are not permitted" error on session creation)
  • Related: #42006 (similar GitHub access check failure on mobile)
  • Related: #41941 (/remote-control stuck in git directories)

View original on GitHub ↗

17 Comments

github-actions[bot] · 3 months ago

Found 2 possible duplicate issues:

  1. https://github.com/anthropics/claude-code/issues/41941
  2. https://github.com/anthropics/claude-code/issues/42507

This issue will be automatically closed as a duplicate in 3 days.

  • If your issue is a duplicate, please close it and 👍 the existing issue instead
  • To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

maxscience · 3 months ago

This has been an issue for around a couple weeks now, still present in the latest 2.1.96 version. Please fix the bug.
A workaround is to open the claude remote-control session in the terminal, then open the Claude desktop app, create a new session and select the local remote-control instance. This way the session will show up in the mobile app correctly but I still can't create new sessions via the mobile app. VScode remote-control always gives the error 'Remote control initialization failed' (this is likely another bug)

druvv · 3 months ago

+1 I'm experiencing this issue.

FelixLisczyk · 3 months ago

I have the same issue. When I start claude remote-control on my Mac, open the session URL in my browser, and start a new session there, it works correctly. I can then see this session in my iOS app as well.

However, when I open the mobile app directly, tap the plus button, select my local environment, and send a message, I get the error message mentioned in the first post.

patricka3125 · 3 months ago

+1

kobajs · 3 months ago

Found a clunky way, hope it works for you guys:

After checking my Github > Settings > Applications > Installed Github Apps > Claude, the repository I wanted wasn't selected. After allowing the repository, worked.
Alternatively, if you try to create a Cloud Environment instead of Remote Control, you might have the permission pop up appearing on Github as well

Now, message might need to be clearer and specially for mobile users, it gets redirected not to Github Mobile, but Browser>Github

mattgvaz · 3 months ago

+1 same issue - Claude Code v2.1.80, macOS, Team plan
My situation is what is described on https://github.com/anthropics/claude-code/issues/41941 but since there are no comments there and it's been flagged as a potential duplicate on this issue, I figured I'd comment here.

fabricehong · 3 months ago

Additional evidence — silent failure on initial session pre-spawn

Same 400 error, different failure mode: the initial pre-spawned session fails to create, so claude remote-control --spawn=same-dir stays stuck at Capacity: 0/32 and no session reaches the mobile app. No error shown in terminal — only --debug-file reveals it:

[bridge:api] POST /v1/environments/bridge -> 200 environment_id=env_...
[bridge] Session creation failed with status 400: source: Extra inputs are not permitted
[bridge:work] Starting poll loop spawnMode=same-dir ...

After the 400, the server enters the poll loop indefinitely and never retries. The UI just shows Ready / Capacity: 0/32 with no visible error. To a user, it looks fine until they check the mobile app and find nothing.

Narrowed cause: the 400 only triggers when git_repo_url points to a GitHub remote. Same directory, same content, same claude 2.1.112 — swapping origin to a Bitbucket HTTPS URL makes the pre-spawn succeed (Capacity: 1/32).

// Fails — git@github.com:.../repo.git            → 400 source: Extra inputs are not permitted
// Fails — https://github.com/.../repo.git        → 400 source: Extra inputs are not permitted
// Works — https://.../bitbucket.org/.../repo.git → 200, Capacity 1/32

Consistent with @kobajs's finding — the check is tied to Claude GitHub App authorization, which is why Bitbucket bypasses it entirely.

Suggested fixes:

  • Don't block session creation on the GitHub access check — Remote Control runs locally, it shouldn't need GitHub API access unless a GitHub-integrated feature is used.
  • Surface the 400 in the terminal UI instead of silently polling. Capacity: 0/32 without a hint is impossible to diagnose without enabling the debug log.
  • Translate the opaque source: Extra inputs are not permitted into something actionable (e.g. point to the Claude GitHub App install URL).

Tested on claude-code 2.1.112, Ubuntu 22.04.

BugraHasbek · 2 months ago

Open https://github.com/settings/installations. Verify Claude is in "Installed Github Apps". Claude can also be in "Authorized github apps" which might confuse developers, because it is not enough to be authorized. Authorized apps do not have access to private repositories.

In order to add claude to "installed github apps", run "/install-github-app" inside claude cli. (It is possible that it might require github cli if it is not already installed in the computer. Go to "https://cli.github.com/" and install the github cli. Then run gh auth login command. Once github is installed, repeat "/install-github-app" in a new terminal. (Claude session in old terminal will not be updated, so close that session)

Once claude is installed as a github app, next time you run "claude remote-control" and either open claude code or claude mobile app you will see "Capacity:1/32" which means connection is successful.

b0nsun9 · 2 months ago

Confirming this still reproduces on a newer Claude Code version.

Environment:

  • Claude Code: 2.1.119 (original report was on 2.1.92 — bug persists in newer version)
  • iOS Claude app: v1.260416.0
  • macOS (Darwin 25.4.0)

Repro: 100% reproducible. Run claude remote-control in a git repository directory, then attempt to create a new session from the iOS app → "Failed to send message — GitHub repository access check failed — re-authorize GitHub in settings".

Workaround confirmed: Starting the session locally first via claude --remote-control and connecting from mobile afterward avoids the error, since session creation isn't initiated from mobile.

Adding +1 — would be great to see this prioritized as it blocks the core "create new session from mobile" flow advertised in the Remote Control docs.

maxscience · 1 month ago

Still the same with v2.1.144 and latest iOS mobile app. Fix it please

Snailflyer · 1 month ago

The failure mode here looks like two separate contracts being coupled too early.

Remote Control is local execution with a remote client surface, so the presence of git_repo_url should probably annotate the environment, not gate basic local session creation. If GitHub authorization is needed for GitHub-specific features, those features can degrade or ask for authorization later; the local remote-control session should still be able to start and accept messages.

The second important part is observability: Capacity: 0/32 plus a hidden source: Extra inputs are not permitted error is not actionable for users. The UI/CLI should distinguish local environment registered from session pre-spawn failed because repo authorization failed, otherwise it looks like mobile Remote Control is randomly broken.

Eskeeet · 1 month ago

same issue

mcolyer · 1 month ago

Another workaround, rename the origin remote to anything else (ie upstream) and the GitHub check no longer fails.

chippydip · 1 month ago

Hit this today on 2.1.172 (Windows 11) — same symptom: an environment registered with a git_repo_url errors on send with the GitHub re-auth message, while environments registered from non-git directories dispatch fine. The local bridge receives zero work items in the failing case, so the check happens entirely service-side before dispatch.

Resolution that worked without touching the remote: re-authorize GitHub from claude.ai settings and make sure the repo's org is included in the grant — org access is a separate approval in GitHub's flow, and a personal-only grant still fails for org-owned repos. After re-auth, dispatch into the same environment worked immediately, including worktree spawns.

+1 that a purely local bridge shouldn't require the claude.ai GitHub connector at all.

FakieHeelflip · 10 days ago

same issue

samuelkitazume · 3 days ago

This is still happening for me too