[BUG] Bash tool with `git push` hangs indefinitely in remote control mode — command never reaches the shell

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 (2.1.92 native binary via nixos-unstable — the latest version available in nixpkgs at the time of writing)

What's Wrong?

When Claude Code is running in remote control mode (accessed via Android Claude app connecting to local CLI), Bash tool invocations containing git push hang indefinitely. The command never reaches the shell — no output is produced and no log files are created even when redirecting to a file. The Bash tool's timeout parameter and the OS timeout command wrapper both have no effect. I have to manually SSH into the machine and kill the process to regain control.

This happens regardless of:

• Whether GIT_TRACE environment variables are set
• Whether output is redirected to a file (> /path/to/log 2>&1)
• Whether the OS timeout command wraps the invocation
• Whether run_in_background is set to true
• The Bash tool's timeout parameter value

The same git push command succeeds instantly when run via a direct SSH session to the same machine's Claude Code CLI (not through remote control mode). HTTPS authentication via gh auth git-credential works correctly — this is not an authentication issue.

Other git commands (git status, git diff, git log, git commit, git fetch) work fine through the Bash tool in the same remote control session.

What Should Happen?

git push via the Bash tool should execute normally and return the command output, just like every other git command.

Error Messages/Logs

# Attempts produce either an immediate internal error or an indefinite hang:
[Tool result missing due to internal error]

# No log file is created, confirming the command never reaches the shell:
$ ls -la /run/user/1000/coding-agent-work/git-push-*.log
ls: cannot access '/run/user/1000/coding-agent-work/git-push-*.log': No such file or directory

# Meanwhile, the same push succeeds via direct SSH session to the CLI:
$ git push origin kyosei/pr-url-args
To https://github.com/ncaq/konoka.git
   94233f3..32db47f  kyosei/pr-url-args -> kyosei/pr-url-args

Steps to Reproduce

1. Set up Claude Code CLI (native binary) on a Linux machine with gh auth login configured (HTTPS, not SSH)
2. Connect to the CLI via remote control mode (Android Claude app, or claude.ai/code)
3. Make a commit on a branch
4. Ask Claude to push: the Bash tool attempts git push origin <branch>
5. Result: hangs indefinitely or produces [Tool result missing due to internal error]
6. To recover: SSH into the machine and kill the hung process
7. Verify: run the same git push command via a direct SSH session to the CLI — succeeds immediately

Note: the issue reproduced on every attempt in the remote control session. A successful trace-enabled push was observed earlier, but that was likely from a direct SSH session to the CLI (not through remote control mode).

Relationship to Existing Issues

I searched extensively and found several related but distinct issues:

Web/container git proxy issues (different problem)

• #11899 — git push fails with 504 Gateway Timeout via internal proxy (127.0.0.1:2xxxx) in Web containers
• #13212 — Git proxy service not running in container environment
• #14377 — Git proxy timeout in Web environment

These involve the Web-hosted container environment's authentication proxy. My issue occurs on a local CLI connected via remote control — there should be no proxy involved. The local gh auth git-credential is the only credential helper in use, and it works correctly when the same command is run via direct SSH.

Bash tool hang/FIFO issues (possibly related mechanism, different symptoms)

• #12650 — Bash tool intermittently hangs when reading from FIFOs (NixOS)
• #10078 — Git process zombies causing sessions to hang

These describe commands that execute but whose completion is never detected. My issue is different: the command never executes at all (no log file created, no process spawned). The error message is internal error, not a timeout.

SSH probe issues (possibly contributing factor)

• #14485 (39 reactions) — Plugin marketplace clone triggers SSH key access prompt
• #21108 (14 reactions) — Claude accesses git origin server on startup
• #16274 (12 reactions) — Marketplace sync triggers YubiKey prompts

These document Claude Code making autonomous SSH probes to git remotes. My environment has no SSH key registered with GitHub (authentication is purely via gh auth HTTPS), so if Claude Code attempts an SSH probe before executing the push, it may fail and cascade into the internal error. However, this is speculative.

Push blocking (different problem)

• #22636 — Push to main blocked by Claude Code's branch protection rules

My pushes are to feature branches, not protected branches, and the error is internal error not a policy block.

Key differentiator

None of the above issues describe the specific combination of symptoms observed here:

1. git push hangs or produces internal error exclusively in remote control mode
2. The command never reaches the shell (no log files created)
3. All other git commands work normally in the same session
4. The same git push succeeds via direct SSH session to the same CLI

Claude Model

claude-opus-4-6[1m] (Claude Opus 4.6 with 1M context)

Is this a regression?

I don't know

Claude Code Version

2.1.92 (Claude Code) — native binary installed via nixos-unstable (nixpkgs)

Platform

Anthropic API

Operating System

Other Linux

Terminal/Shell

Other

Additional Information

• OS: NixOS 25.11 (Linux 6.12.78)
• Shell: zsh
• Git: 2.51.2
• GitHub CLI: 2.83.2
• Claude Code: native binary (not npm), installed via nixos-unstable nixpkgs
• Authentication: gh auth login (HTTPS protocol, gh auth git-credential as credential helper)
• No SSH keys registered with GitHub (GPG keys only, for commit signing)
• Remote control mode: local CLI accessed via Android Claude app
• Direct SSH session to the same CLI: git push always succeeds
• A successful trace-enabled push was observed earlier, but that was likely from a direct SSH session to the CLI, not through remote control mode.