The Token-in-URL Way of Authenticating git Stopped Working in One Scheduled Task

Step 1: call git without leaving the token in arguments or config

I chose GIT_ASKPASS with the token read from a file. The wrapper writes the value to a temporary file and always removes it on exit.

#!/bin/bash
# ghgit.sh — a thin wrapper that calls git without putting the token in a URL or an argument
# Usage: ghgit.sh "label" <git subcommand and arguments...>
set -euo pipefail
LABEL=${1:?usage: ghgit.sh "label" <git arguments...>}; shift
TOKENS=${TOKENS_FILE:?set TOKENS_FILE to the path of your token ledger}
 
tok=$(mktemp "$HOME/.ghtok.XXXXXX"); chmod 600 "$tok"
ask=$(mktemp "$HOME/.ghask.XXXXXX")
trap 'rm -f "$tok" "$ask"' EXIT
 
# The ledger format is "label line, then the token on the next line". Never echo the value.
{ grep -A1 -F -- "$LABEL" "$TOKENS" || true; } | tail -n 1 | tr -d "[:space:]" > "$tok"
[ -s "$tok" ] || { echo "ghgit: no token found for label '$LABEL'" >&2; exit 2; }
 
cat > "$ask" <<'ASK'
#!/bin/sh
case "$1" in
  Username*) echo x-access-token ;;
  *)         cat "$GHGIT_TOKEN_FILE" ;;
esac
ASK
chmod 700 "$ask"
 
GHGIT_TOKEN_FILE="$tok" GIT_ASKPASS="$ask" GIT_TERMINAL_PROMPT=0 git "$@"

To use it, put ghgit.sh "label" in front of git. The URLs stay free of credentials.

export TOKENS_FILE="$HOME/secrets/tokens.txt"   # adjust to wherever yours lives
 
./ghgit.sh "My Repo" clone --depth 1 --branch main https://github.com/OWNER/REPO.git work
./ghgit.sh "My Repo" -C work pull --rebase origin main
./ghgit.sh "My Repo" -C work push origin main

Here is why each piece is written the way it is.

• GIT_ASKPASS asks for the user name and the password separately. Branching on whether the prompt starts with Username keeps the script short. For a GitHub token, x-access-token worked as the user name
• The token never goes into an environment variable; only the file's location does. A value in the environment can be read by other processes of the same user. A file can be limited with mktemp and chmod 600, and trap removes it on exit
• GIT_TERMINAL_PROMPT=0 is there on purpose. In an unattended run nobody can answer a prompt, and I would rather git fail immediately than wait
• The remote of the working repository stays a plain URL. If someone opens the config file, there is no token to find

What I checked: clone, pull and push --dry-run all went through (the remote of the cloned repository remained a credential-free URL). While a run was in flight, ps showed only git ls-remote https://..., and zero lines containing the token. The environment of the running git process did not contain the token string either.

Step 2: do not let a missing label end the script silently

The first version of this wrapper ended in silence. Call it with a wrong label and it printed nothing and returned exit code 1.

# First version (broken)
grep -A1 -F -- "$LABEL" "$TOKENS" | tail -n 1 | tr -d '[:space:]' > "$tok"
[ -s "$tok" ] || { echo "ghgit: ..." >&2; exit 2; }   # never reached

With set -e and pipefail, the moment grep found nothing (exit code 1) the whole pipeline failed and the script exited. The message I wrote for exactly this case never got a chance to run. In a scheduled task that leaves a log with a failure and no explanation, which is the form I find hardest to read afterwards. Wrapping only the grep in braces with || true, and moving the judgment to the empty-file check on the next line, produced the message and exit code 2.

Treat "not found" as an ordinary outcome first, then stop with your own words. That order keeps the cause readable in the log. I wrote about the same idea of checking results before exiting in the end-of-run assertion article.

Step 3: count the repositories that still have a token in the URL

Even after switching to the new form, the .git/config of every repository you created earlier still holds the old token. Before changing anything, count them with a read-only script. It never prints the token itself.

#!/bin/bash
# Count git repositories directly under a folder whose remote URL has credentials embedded.
# Read-only. The contents of the URL (the token itself) are never printed.
root=${1:?usage: scan_remote_creds.sh <folder that holds your repositories>}
total=0; embedded=0
for d in "$root"/*/; do
  [ -d "$d/.git" ] || continue
  total=$((total + 1))
  # Look at every remote, not only origin
  while read -r name; do
    url=$(git -C "$d" remote get-url "$name" 2>/dev/null) || continue
    case "$url" in
      *://*@*) embedded=$((embedded + 1)); echo "embedded: ${d%/} ($name)";;
    esac
  done < <(git -C "$d" remote)
done
echo "${embedded} remote(s) with credentials across ${total} repositories"

I ran it on two dummy repositories, one with a token and one without, and got this.

embedded: /.../scan/r1 (origin)
1 remote(s) with credentials across 2 repositories

Anything it finds can go back to a credential-free URL with git remote set-url origin https://github.com/OWNER/REPO.git. After that, I'd also regenerate any token that was ever written into a URL, because config files can be copied by folder-sync services and backups.

Pitfalls

• The "redirecting" warning appeared with every form. The warning alone is not a sign of failure. Look at the trace to see whether authentication survived or dropped after it
• I did not try other git versions. I used 2.34.1. Newer versions may treat credentials embedded in a URL differently
• Environments with a credential helper may behave differently. There was no helper here, so GIT_ASKPASS was used. I haven't tried setups that already have one, such as a macOS keychain integration
• The wrapper depends on the ledger format. It assumes the token sits on the line after the label, so a label on the last line would pull in the label line itself. If a label matches several lines, the line after the last match is used
• trap does not run on a forced kill. While testing, I stopped a running git with pkill, my working shell went down with it, and four .ghtok.* and .ghask.* files stayed in my home folder. They held the real token. I deleted them right away, but the warning about forced kills turned out to be a personal one. A line at startup that removes stale .ghtok.* files would make it safer still
• Visible arguments only matter on a shared machine. My environment has a single user, so even extraHeader would have been low-risk. I still prefer to write the procedure in the form that leaves the least behind

Where I drew the line

Working is not the same as adopting it. In this case, getting git to pass was only the first half; the second half was making it leave nothing behind.

As an indie developer who runs websites alone, I'd suggest starting with the Step 3 script, run read-only on the folder where your repositories live. Zero is the best result. If it finds even one, decide whether to regenerate that token before you change the URL back.