How Go Fetches Private GitHub Repositories and Fixes "terminal prompts disabled"

By the end of this page, you will understand why go get fails when accessing a private GitHub repository over HTTPS, why Go disables interactive credential prompts, and how to fix it using Git authentication and Go private-module settings such as GOPRIVATE.

When Go downloads code from a version control host like GitHub, it often delegates the actual network operation to tools such as git. For public repositories, this usually works without authentication. For private repositories, GitHub requires credentials.

The confusing part is that go get is not designed to stop and ask you for a GitHub username and password interactively in the terminal. Instead, Go runs Git in a non-interactive mode. That is why you see this message:

fatal: could not read Username for 'https://github.com': terminal prompts disabled

This does not mean your repository is broken. It means Git tried to access a private repository over HTTPS, needed credentials, and was not allowed to prompt for them.

Why this matters

In real projects, private modules are common:

• internal company libraries
• shared backend packages
• private SDKs
• monorepo submodules split into separate repositories

To use them reliably, you need two things configured correctly:

1. Authentication for Git

   • SSH keys, or
   • HTTPS with a credential helper or personal access token

2. Private module settings for Go

   • usually GOPRIVATE, so Go knows the module is private and should not use the public proxy/checksum flow for it

Important modern note

Older examples often show go get for downloading code into $GOPATH. In modern Go, modules are the standard approach. You will more commonly use:

go get github.com/examplesite/myprivaterepo

inside a module, or add it to go.mod through imports and go mod tidy.

The root issue is still the same: Go can only fetch a private GitHub repo if Git already knows how to authenticate non-interactively.

Think of go get as a delivery manager and git as the courier.

• go get says: "Please fetch this package."
• git goes to GitHub to pick it up.
• GitHub says: "This package is private. Show credentials."
• The courier looks back for input, but the manager has said: "Do not stop and ask questions."

So the delivery fails.

The fix is to give the courier a badge before the trip starts:

• an SSH key
• a stored token
• a credential helper

Then Git can authenticate automatically, and Go no longer needs to prompt.

Common fixes

Option 1: Use SSH for GitHub access

Generate an SSH key if you do not already have one:

ssh-keygen -t ed25519 -C "you@example.com"

Add the public key to your GitHub account.

Then configure Git to use SSH instead of HTTPS for GitHub:

git config --global url."git@github.com:".insteadOf "https://github.com/"

Now when Go tries to fetch:

go get github.com/examplesite/myprivaterepo

Git will internally use SSH:

git@github.com:examplesite/myprivaterepo

That avoids the HTTPS username/password prompt problem.

Option 2: Use HTTPS with a credential helper

Install and configure a Git credential helper so Git can supply credentials automatically.

Example on macOS:

git config --global credential.helper osxkeychain

Then authenticate once using GitHub with a personal access token when Git asks through a normal Git command.

Option 3: Tell Go the module is private

For private GitHub repositories, set GOPRIVATE:

go env -w GOPRIVATE=github.com/examplesite/*

You can verify it with:

go env GOPRIVATE

This tells Go that modules matching that pattern are private.

Example workflow with SSH

go env -w GOPRIVATE=github.com/examplesite/*
git config --global url."git@github.com:".insteadOf "https://github.com/"
go get github.com/examplesite/myprivaterepo

What this does

• GOPRIVATE tells Go not to treat the module like a public one.
• insteadOf makes Git use SSH for GitHub.
• go get can now fetch the private repository without interactive prompts.

Consider this command:

go get github.com/examplesite/myprivaterepo

Here is what happens step by step.

Case: broken setup

1. Go resolves the module path

Go sees:

github.com/examplesite/myprivaterepo

and decides it needs to download code from GitHub.

2. Go invokes Git

Behind the scenes, Go may run something similar to:

git clone https://github.com/examplesite/myprivaterepo

3. GitHub requires authentication

Because the repository is private, GitHub refuses anonymous access.

4. Git wants credentials

Git tries to obtain a username and password or token.

5. Prompts are disabled

Because Go launched Git in non-interactive mode, Git cannot ask:

fatal: could not read Username for 'https://github.com': terminal prompts disabled

6. Go reports failure

Git exits with a non-zero status, and Go forwards the error.

Case: fixed setup with SSH

1. You configure GitHub SSH access

Git already has a usable SSH key.

2. Git is told to replace HTTPS with SSH

git config --global url."git@github.com:".insteadOf "https://github.com/"

3. Go runs the fetch again

go get github.com/examplesite/myprivaterepo

4. Git uses SSH automatically

Instead of trying HTTPS, Git connects using your SSH identity.

5. Authentication succeeds without prompts

Since the SSH key is already available, no username/password prompt is needed.

6. The repository downloads successfully

Go can now complete the operation.

Private repository access is common in many real development environments.

Internal shared libraries

A team might keep reusable Go packages in private GitHub repositories:

• authentication helpers
• logging packages
• company-specific API clients

Applications import them as private modules.

Microservices in one organization

A backend service might depend on shared contracts or utilities stored privately:

import "github.com/examplesite/platform/auth"

If Git authentication is not configured on CI or developer laptops, builds fail.

CI/CD pipelines

Build servers often need to fetch private modules. Since CI jobs are non-interactive, this exact problem appears there too. That is why token-based or SSH-based authentication is essential.

Onboarding a new machine

Your question is a classic example: one machine already had working credentials, while the new laptop did not. The repository itself was fine; the new environment simply lacked non-interactive Git authentication.

In real projects, developers usually solve this once at the environment level rather than per repository.

Common patterns

1. Set GOPRIVATE for the organization

go env -w GOPRIVATE=github.com/examplesite/*

This is common in companies with multiple private modules.

2. Prefer SSH for developer machines

SSH is often easier for repeated access across many repos:

git config --global url."git@github.com:".insteadOf "https://github.com/"

3. Use tokens in CI

CI systems usually inject a GitHub token and configure Git before running go mod download or go test.

4. Validate setup early

Teams often add setup docs such as:

ssh -T git@github.com

or:

git ls-remote git@github.com:examplesite/myprivaterepo.git

This checks authentication before debugging Go.

5. Keep Go module commands non-interactive

A good workflow assumes commands like these must work without prompts:

go mod tidy
go test ./...
go build ./...

If any of them depend on manual credential entry, automation becomes fragile.

1. Expecting go get to ask for a GitHub username and password

Beginners often assume this will happen:

go get github.com/examplesite/myprivaterepo

But Go usually runs Git non-interactively, so no prompt appears.

2. Using HTTPS without stored credentials

Broken setup:

go get github.com/examplesite/myprivaterepo
# Git tries https://github.com/... and needs credentials

Fix it by using:

• SSH keys, or
• a credential helper with a token

3. Forgetting GOPRIVATE

Without GOPRIVATE, Go may try public module infrastructure for a private repo.

Fix:

go env -w GOPRIVATE=github.com/examplesite/*

4. Assuming the first machine proves the second is configured

One computer working does not mean another one has the same:

• SSH keys
• Git config
• token storage
• Go environment variables

Each machine needs its own setup.

5. Using old GOPATH-era assumptions

Older tutorials focus on cloning into $GOPATH/src. Modern Go uses modules, so authentication problems are usually about module fetching, not just GOPATH layout.

6. Using GitHub password authentication

GitHub no longer supports normal account passwords for Git operations over HTTPS in the way older workflows expected. Use:

• personal access tokens for HTTPS
• SSH keys for SSH access

Broken example vs fixed example

Broken:

go get github.com/examplesite/myprivaterepo
# fails because Git has no non-interactive credentials

Fixed:

go env -w GOPRIVATE=github.com/examplesite/*
git config --global url."git@github.com:".insteadOf "https://github.com/"
go get github.com/examplesite/myprivaterepo

go get vs git clone

GOPATH mode vs module mode

# Mark GitHub organization repos as private for Go
go env -w GOPRIVATE=github.com/examplesite/*

# Verify
go env GOPRIVATE

# Use SSH instead of HTTPS for GitHub
git config --global url."git@github.com:".insteadOf "https://github.com/"

# Test SSH access
ssh -T git@github.com

# Test direct repo access
git ls-remote git@github.com:examplesite/myprivaterepo.git

Key ideas

• go get often runs Git in non-interactive mode.
• Private repos require preconfigured authentication.
• terminal prompts disabled means Git needed credentials but could not ask for them.
• GOPRIVATE tells Go a module should be treated as private.
• Preferred auth options:
  • SSH keys
  • HTTPS with personal access token and credential helper

Typical fix

1. Configure GitHub authentication.
2. Set GOPRIVATE.
3. Retry go get or go mod tidy.

Common commands

go get github.com/examplesite/myprivaterepo
go mod tidy
go mod download

All of these may fail if private Git access is not configured.

Why does go get say terminal prompts disabled?

Because Go invoked Git in a non-interactive way, and Git needed credentials for a private repository but was not allowed to prompt.

Should go get ask for my GitHub username and password?

Usually no. You should configure Git authentication in advance using SSH keys or a token-based credential helper.

Do I need GOPRIVATE for private GitHub repositories?

Yes, in most modern Go setups it is recommended. It tells Go which module paths are private.

Is SSH better than HTTPS for private Go modules?

For many developer machines, yes. SSH avoids repeated credential prompts and works well with go get once keys are configured.

Can I still use HTTPS instead of SSH?

Yes, but you should use a GitHub personal access token and a Git credential helper rather than relying on interactive prompts.

Why did it work on one computer but not the other?

The first machine probably already had valid Git credentials, cached authentication, or SSH keys. The new laptop did not.

Is this a Go problem or a Git problem?

It is mainly an authentication/configuration issue involving both. Go starts the fetch, but Git performs the repository access.

Does this still matter with modern Go modules?

Yes. The exact commands may differ, but private module access still depends on proper Git authentication and GOPRIVATE configuration.

• Go modules — Modern Go dependency management; private repositories are commonly used as modules.
• GOPRIVATE — Tells Go which module paths should be treated as private.
• Git authentication — The underlying reason private repository access succeeds or fails.
• SSH keys — A common non-interactive authentication method for GitHub.
• Git credential helpers — Used to store and provide HTTPS credentials automatically.
• Personal access tokens — The modern replacement for GitHub password-based Git access over HTTPS.
• go mod tidy — Often triggers private module downloads, so it hits the same auth issues.
• git clone vs go get — Helpful comparison because direct Git commands may behave differently from Go-managed fetches.