Conclusion

• With a command such as git clone https://username:token@host/repository.git, putting the token in the URL and cloning stores the token in plaintext on the url = line in .git/config (verified on an actual machine on 2026-11-11 using Git 2.47.3, dummy values, and a local HTTP server).
Running git remote -v displayed the token verbatim. This is a command AI agents often use when checking the state of a repository (the claim that it is often used is speculation; I did not count the number of occurrences).
• When I packaged the project as a tar archive, the token was included along with .git/config.
Running git fetch with GIT_TRACE=1 caused the URL containing the token to appear verbatim in the trace output.
By contrast, in the fatal: unable to access ... error message shown when the connection failed, the token portion was absent.
With git -c transfer.credentialsInUrl=warn, Git can issue a warning; with =die, it can abort. The token in the message was replaced with <redacted>.
After correcting the URL with git remote set-url origin https://host/repository.git, the token string was no longer present anywhere under .git (confirmed with grep -r).

This article is part of a verification series on “AI Agents and Secrets.” New verification results are also announced on X (@supportapp3_lab).

Try it (check whether the token is included in the remote URL)

Run the following in the repository directory. If there is no output, remote.*.url does not contain any URLs in the username:password@ format.

The token is displayed in the output exactly as it is. Be careful when sharing your screen or before pasting it into a chat with an AI.

What is the problem?

CI examples and guides sometimes show how to write the token in a URL, such as https://x-access-token:<token>@github.com/... . If you use this method once locally, the token will remain in .git/config.

AI agents may run git remote -v or cat .git/config while working, or read folders containing .git. In such cases, the token could end up in conversation history or logs (speculation; I have not actually run any AI tools for this article).

What I verified on an actual machine

Using the dummy token ghp_DUMMY000…, I cloned from a local HTTP server (serving a bare repository via python3 -m http.server).

.git/config after cloning

No warning was displayed when cloning (default settings).

Output by command

Command	Did the token appear?
git remote -v	It appeared (on both the fetch and push lines)
cat .git/config	It appeared
.git/config inside the archive created with tar czf	It was included
GIT_TRACE=1 git fetch	It appeared (run_command: ... git remote-https origin https://x-access-token:ghp_...@...）
fatal: unable to access when the connection fails	It did not appear (it displayed https://127.0.0.1:9/demo/repo.git/)
GIT_CURL_VERBOSE=1 git fetch (when the connection fails)	It did not appear

GIT_CURL_VERBOSE was checked only for cases where the connection fails. I have not tested how it behaves when the connection succeeds and the server requests authentication.

transfer.credentialsInUrl

With die, it stopped with exit code 128, before the unable to access connection error.

Git's official documentation (transfer.credentialsInUrl in git-config) states the following.

• The default is allow, so it proceeds without a warning.
This applies to remote..url; credentials entered in remote..pushurl are not detected.
Git programs pass URLs to one another as command-line arguments, so they may be visible in the process list to other users.

I have not tested the behavior of pushurl locally (based only on the official documentation). The issue of arguments being visible in the process list was verified separately by writing the API key as a command-line argument, where it is fully visible to another user through ps.

Countermeasures

In my local environment, afterward, `grep -rl ghp_DUMMY .git` no longer found anything. If `pushurl` is configured, check it with `git config --get-regexp '^remote\.'` and fix that as well.

1. Pass tokens through a credential helper (`git-credential`), rather than in a URL. For GitHub, you can run `gh auth login` followed by `gh auth setup-git`, among other options.
2. Configure it to issue warnings so that you can notice such cases routinely.

1. A token that has once been written into a URL may have been copied somewhere, so consider regenerating (revoking) it at the source.
2. When packaging a project as a zip or tar archive and giving it to an AI, do not include `.git` (packaging it with tar or zip can also include `.env` and the `.git` history).

About ai-secret-check

`ai-secret-check scan` searches for .env-relatedfilenamesin places an AI may be able to read (it does not display their contents). It does not inspect URLs inside `.git/config`, so use it together with the `git config` check above.

Repository: https://github.com/supportapp3-lab/ai-secret-check (Node.js 20 or later, MIT)

References

• git-config (`transfer.credentialsInUrl`) https://git-scm.com/docs/git-config
• gitcredentials https://git-scm.com/docs/gitcredentials
• Related: API keys are fully exposed by `console.log(err)` in axios / committed `.env` files can be read from Git history / keys appear in the output with `bash -x`

※ Verified on 2026-11-11 with Debian 13, Git 2.47.3, dummy values, and a local HTTP server.

Updates and occasional tips are posted on X (@supportapp3_lab).