When cloning git repositories in automated tools - web front ends, CI systems, sometimes the git clone invocation opens up a prompt asking for the username and password (for example, when cloning a non-existent Github repo or on a new node missing ssh keys).

How do I make git just fail (preferably with a sensible error message and exit code) instead of waiting for the server process to give it a username and password?

  • We have a multi-server Jenkins set up, which annoyingly sits waiting for a prompt until killed if it runs on a new server missing the ssh keys - a way to configure that it will simply fail with a message and non-zero exit code would be useful. Commented Dec 2, 2013 at 14:46
  • If a catch all "batch" mode could be used to disallow prompting for host keys too - this would be ideal. Commented Dec 2, 2013 at 14:55
  • These are both related - trying to piece them together - serverfault.com/questions/61915/…, stackoverflow.com/questions/7772190/…. Commented Dec 2, 2013 at 15:06

7 Answers 7


In git version 2.3 there's an environment variable GIT_TERMINAL_PROMPT which when set to 0 will disable prompting for credentials.

You can get more info about it in man git (after updating to git version 2.3) or in this blog post on github.


  • git clone https://github.com/some/non-existing-repo will prompt for username & password
  • GIT_TERMINAL_PROMPT=0 git clone https://github.com/some/non-existing-repo will fail without prompting for username & password
  • Frustrating to be back here with an https git clone, on an el7 server with git 1.8. Going to check if updating to 2.0 from the other repo is an option for it. Commented Oct 11, 2019 at 15:33
  • 1
    For me, git 2.36.1 will still invoke ksshpass, though. Commented Jun 11, 2022 at 20:49

How to skip, ignore and/or reject git credentials prompts

The answers above only worked partly for me when using Git-for-Windows: two different applications there were vying for my attention from the automated git pull/push scripts:

  • git-credentials-manager (developed by the GfW team AFAICT; has a clean, grey Windows interface look)
  • another dialog, which' ancestry has some definitely (crappy looking) X-Windows genes.

To shut all of them up, without uninstalling the credentials manager as mentioned in some answers here: https://stackoverflow.com/questions/37182847/how-do-i-disable-git-credential-manager-for-windows, here's what now works, sitting on top of the automated (bash) shell scripts:

# https://serverfault.com/questions/544156/git-clone-fail-instead-of-prompting-for-credentials
# next env var doesn't help...
export GIT_SSH_COMMAND='ssh -oBatchMode=yes'
# these should shut up git asking, but only partly: the X-windows-like dialog doesn't pop up no more, but ...
export GIT_ASKPASS=echo
export SSH_ASKPASS=echo
# We needed to find *THIS* to shut up the bloody git-for-windows credential manager: 
# https://stackoverflow.com/questions/37182847/how-do-i-disable-git-credential-manager-for-windows#answer-45513654
export GCM_INTERACTIVE=never

What did NOT work

  • All the incantations of git config credential.modalprompt false -- mentioned as a solution in answers to that linked SO question. no dice for me.
  • fiddling with that GIT_SSH_COMMAND environment variable: nothing worked but keeping it as I suspect it'll kick in when running this stuff on a Linux box instead of Windows.
  • GIT_TERMINAL_PROMPT=0: no worky either. Kept it in for the same reason, but no dice on Windows.

Oh, and uninstalling the git credentials manager as suggested in other answers in that SO link was decided a no go option as it would definitely impact other repository trees where this thing may be useful one day. Though it was considered for a bit, before I decided against doing this.

What DID work

My git version

$ git --version
git version 2.30.1.windows.1

Parting note

<rant> Been looking for this info on-and-off for years: this time apparently I was lucky and maybe persevered longer(?), wading through the zillion pages yakking about setting up your credentials: google clearly is not intelligent. At least it does not listen very well to minority questions, that's for sure. </rant>

The title is added in hopes that google indexing places this page higher for the next one looking for answers to these questions or variations therefor...

  • Is it possible to have this work when run in a .bat file? Commented Jul 20, 2023 at 23:57

If you are using ssh authentication, and on linux, then you can create an ssh command replacement to disable this.

Create a file called "sshnoprompt.sh" with:

ssh -oBatchMode=yes $@

Make this file executable with chmod +x sshnoprompt.sh

Then when starting git:

GIT_SSH="sshnoprompt.sh" git clone foo@dummyserver:not_a_repo

And it will not allow any interactive git prompts or questions - it shouldn't be able to ask the user for anything.

  • 1
    This is what I needed. Thank you. Did not guess myself that ssh is different and therefore GIT_TERMINAL_PROMPT and core.askPass do not work. Alternative: GIT_SSH_COMMAND='ssh -oBatchMode=yes' git clone foo@dummyserver:not_a_repo
    – simohe
    Commented May 22, 2020 at 12:19
GIT_TERMINAL_PROMPT=0 git clone https://github.com/some/non-existing-repo

Work for me on Mac.


Working from git version;

git clone -c core.askPass $echo url/or/path/to/git/repo

The configuration core.askPass works by passing the control of handling credentials to the aforementioned program. However since $echo cant do anything except output, the clone attempt promptly fails and respective bash redirection applies. This code is only invoked in the event that the git repository happens to be private, and will pipe error output stating that authentication failed for the particular repository. You can test this against the https://github.com/git/git public repository against a private repository you know about.

To sweeten the deal, you wouldn't even need to reference a program like echo in the first place. Simply passing git configuration -c core.askPass with no following input would still cause failure in the event the repository happens to be private as the code will not know what program to offload credential handling to. While this is certainly an older and simpler method than the others mentioned here, I do not know if it will have the same effect in older versions of git.

  • 1
    You are somewhat correct while being very wrong. First of all, in your case $echo is a variable reference which (being unset) expands to empty string, so it's entirely meaningless. If you put echo in there (without the dollar sign), it would also be incorrect since it would be interpreted as repository location. It'd have to be -c core.askPass=echo. Commented Nov 28, 2019 at 13:31
  • I would recommend using "false" or "/usr/bin/false" because that's a command that will always fail.
    – xdevs23
    Commented Jun 26, 2022 at 14:10

When you only have control over the git configuration:

git config --global credential.helper '!f() { echo quit=1; }; f'


$ git clone https://github.com/edx/drf-extensions.git/
Cloning into 'drf-extensions'...
fatal: credential helper '!f() { echo quit=1; }; f' told us to quit

The idea comes from the original committer of GIT_TERMINAL_PROMPT after following @user243345's link.


Depending on how you're running git, redirecting stdin or stdout so that they are not connected to terminals will stop git from prompting for details and just cause it to error.

This would also allow you to surface errors (or at least logs) to the webservice.

  • How exactly would I go about doing this? Trying to accomplish this in Bash first, both </dev/null and nohup .. & don't seem to work. Commented Oct 15, 2013 at 21:56
  • This answer is not helpful without a specific example how to achieve this. Especially that the 'obvious' methods don't work, as mentioned above. Commented Nov 28, 2019 at 13:28
  • @MichałGórny I hadn't seen the OPs question a few years back, but there wasn't enough information in the question (OS, Toolset) to be able to answer that. Redirecting stdin and stdout. Git has changed a lot since the question was asked (on Windows for example, it pops up external dialogs for credentials if you are connecting to Azure DevOps) so you're better off using the environment variable listed in the top answer Commented Nov 28, 2019 at 13:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .