Question
I created a private GitHub repository named examplesite/myprivaterepo using the GitHub web interface.
On one machine, I changed into my Go workspace and fetched the repository successfully:
cd "$GOPATH"
go get github.com/examplesite/myprivaterepo
After that, I created a file, committed it, and pushed it without any issues:
vim scheduler.go
git add scheduler.go
git commit
git push
However, on a different laptop that has not accessed this repository before, I tried the same go get command and got this error:
cd "$GOPATH"
go get github.com/examplesite/myprivaterepo
Output:
cd .; git clone https://github.com/examplesite/myprivaterepo /Users/tom/go/src/github.com/examplesite/myprivaterepo
Cloning into '/Users/tom/go/src/github.com/examplesite/myprivaterepo'...
fatal: could not read Username for 'https://github.com': terminal prompts disabled
package github.com/examplesite/myprivaterepo: exit status 128
Why does go get fail for a private GitHub repository with terminal prompts disabled, and how should I configure Go and Git so the repository can be fetched correctly on a new machine?
Short Answer
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.
Concept
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:
-
Authentication for Git
- SSH keys, or
- HTTPS with a credential helper or personal access token
-
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
- usually
Important modern note
Older examples often show go get for downloading code into . In modern Go, modules are the standard approach. You will more commonly use:
Mental Model
Think of go get as a delivery manager and git as the courier.
go getsays: "Please fetch this package."gitgoes 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.
Syntax and Examples
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:
Step by Step Execution
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
Real World Use Cases
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.
Real Codebase Usage
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:
Common Mistakes
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 . Modern Go uses modules, so authentication problems are usually about module fetching, not just GOPATH layout.
Comparisons
| Approach | How it works | Good for | Drawbacks |
|---|---|---|---|
| HTTPS without credential helper | Git accesses https://github.com/... and needs credentials each time | Almost never ideal for private Go modules | Fails in non-interactive go get workflows |
| HTTPS with credential helper + token | Git stores or retrieves a token automatically | Developer machines and CI | Requires token management |
| SSH with key-based auth | Git accesses git@github.com:... using an SSH key | Most developer setups | Requires SSH key setup |
| Public repo access | No authentication required | Open-source modules | Not suitable for private code |
go get vs
Cheat Sheet
# 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 getoften runs Git in non-interactive mode.- Private repos require preconfigured authentication.
terminal prompts disabledmeans Git needed credentials but could not ask for them.GOPRIVATEtells Go a module should be treated as private.- Preferred auth options:
- SSH keys
- HTTPS with personal access token and credential helper
Typical fix
- Configure GitHub authentication.
- Set
GOPRIVATE. - Retry
go getorgo mod tidy.
Common commands
go get github.com/examplesite/myprivaterepo
go mod tidy
go mod download
FAQ
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.
Mini Project
Description
Create a small Go project that depends on a private GitHub module and configure your machine so dependency downloads work without interactive prompts. This mirrors real development environments where internal packages must be fetched automatically.
Goal
Set up a Go environment that can successfully download a private GitHub repository using non-interactive authentication.
Requirements
- Create or use a private GitHub repository under your account or organization.
- Configure Git authentication using either SSH keys or HTTPS with a credential helper.
- Set
GOPRIVATEto match your private repository path. - Create a local Go module that imports the private package.
- Run a Go command such as
go mod tidyorgo buildsuccessfully.
Keep learning
Related questions
Check if a Value Exists in a Slice in Go
Learn how to check whether a value exists in a slice in Go, and why Go has no Python-style `in` operator for arrays or slices.
Concatenating Slices in Go with append
Learn how to concatenate two slices in Go using append and the ... operator, with examples, pitfalls, and practical usage.
Convert String to Integer in Go: Idiomatic Parsing with strconv.Atoi
Learn the idiomatic way to convert a string to an int in Go using strconv.Atoi, with examples, errors, and common mistakes.