[GH-ISSUE #387] Git Clone Repo tries to authenticate with "token" and "<TOKEN>" #22122

New Issue

GiteaMirror · 2026-06-10T20:01:26-05:00

GiteaMirror commented

2026-06-10 20:01:26 -05:00

Originally created by @marrobHD on GitHub (Mar 29, 2025).
Original GitHub issue: https://github.com/moghtech/komodo/issues/387

The feature "Git Clone Repo" tries to authenticate with "token" and "<TOKEN>" instead of using the specified user and password.

The komodo error shows command:
git clone https://token:<TOKEN>@gitserver.de/ORG/docker-komodo /etc/komodo/repos/<TOKEN> -b main

Gitea shows error:
routers/web/web.go:124:func7() [E] Failed to verify user: user does not exist [uid: 0, name: token]

Using latest tag.

Originally created by @marrobHD on GitHub (Mar 29, 2025). Original GitHub issue: https://github.com/moghtech/komodo/issues/387 The feature "Git Clone Repo" tries to authenticate with "token" and "\<TOKEN\>" instead of using the specified user and password. The komodo error shows command: `git clone https://token:<TOKEN>@gitserver.de/ORG/docker-komodo /etc/komodo/repos/<TOKEN> -b main` Gitea shows error: `routers/web/web.go:124:func7() [E] Failed to verify user: user does not exist [uid: 0, name: token]` Using `latest` tag.

GiteaMirror added the enhancement 1.19.2 labels 2026-06-10 20:01:27 -05:00

GiteaMirror commented

2026-06-10 20:01:28 -05:00

@TheNickOfTime commented on GitHub (Apr 3, 2025):

I am having this issue as well. Basically all git operations fail. Using the previous version has no issues.

@TheNickOfTime commented on GitHub (Apr 3, 2025): I am having this issue as well. Basically all git operations fail. Using the previous version has no issues.

GiteaMirror commented

2026-06-10 20:01:29 -05:00

@mbecker20 commented on GitHub (Apr 3, 2025):

This works with git access tokens, are you able to create an access token on your git provider and use that as the token?

@mbecker20 commented on GitHub (Apr 3, 2025): This works with git access tokens, are you able to create an access token on your git provider and use that as the token?

GiteaMirror commented

2026-06-10 20:01:29 -05:00

@TheNickOfTime commented on GitHub (Apr 4, 2025):

I was using an access token - I'm not sure what my issue was because it isn't happening anymore. Previously I was getting an error on cloning a repo along the lines of Failed to clone repo - too many arguments even though the git clone command it was reporting it was issuing worked fine if I copy and pasted it into my local environment. Originally going back to the last 1.16.x release fixed things for me, but I just tried a fresh install with 1.17.0 to reproduce the issue I was having and everything is working fine so far. 🤷

P.S. I appreciate your work on this project - having my container stacks deploy and update when I merge PRs from renovate is basically black magic 🙏

@TheNickOfTime commented on GitHub (Apr 4, 2025): I was using an access token - I'm not sure what my issue was because it isn't happening anymore. Previously I was getting an error on cloning a repo along the lines of `Failed to clone repo - too many arguments` even though the git clone command it was reporting it was issuing worked fine if I copy and pasted it into my local environment. Originally going back to the last 1.16.x release fixed things for me, but I just tried a fresh install with 1.17.0 to reproduce the issue I was having and everything is working fine so far. 🤷 P.S. I appreciate your work on this project - having my container stacks deploy and update when I merge PRs from renovate is basically black magic 🙏

GiteaMirror commented

2026-06-10 20:01:29 -05:00

@TheTrojan007 commented on GitHub (Apr 9, 2025):

I had the same issue as @marrobHD. Also using the latest tag (v1.17.0).

The apllication tried to clone the repo with "git clone https://token:<TOKEN>@gitea.servername.com/..."
During diagnosing the issues the "<TOKEN>" part actually disappeared completely and now tries to authenticate without any token: "git clone https://token:@gitea.servername.com/..."

I am using a git account added manually in the Settings>Providers section with a working token (I tried "git clone https://token:actualToken@gitea.servername.com/..." locally and it worked)

@TheTrojan007 commented on GitHub (Apr 9, 2025): I had the same issue as @marrobHD. Also using the latest tag (v1.17.0). The apllication tried to clone the repo with "git clone https://token:<TOKEN\>@gitea.servername.com/..." During diagnosing the issues the "\<TOKEN\>" part actually disappeared completely and now tries to authenticate without any token: "git clone https://token:@gitea.servername.com/..." I am using a git account added manually in the Settings>Providers section with a working token (I tried "git clone https://token:actualToken@gitea.servername.com/..." locally and it worked) ![Image](https://github.com/user-attachments/assets/09361c88-e915-4287-a1fd-fbd8dbc82ee9) ![Image](https://github.com/user-attachments/assets/7f78c250-a92c-4160-919c-4199924a4c94) ![Image](https://github.com/user-attachments/assets/01296d31-a4bd-41df-a6d3-4ee2022be623)

GiteaMirror commented

2026-06-10 20:01:30 -05:00

@Zylatis commented on GitHub (May 5, 2025):

Same issue as above

@Zylatis commented on GitHub (May 5, 2025): Same issue as above

GiteaMirror commented

2026-06-10 20:01:30 -05:00

@HumnResources commented on GitHub (May 6, 2025):

Bump. Confirm same issue. Managed to resolve it once before by reinstalling but that was after multiple attempts/versions. Double checked the token is valid and has access, just appears to not be passed through to the command. In both cases, my git auth failed after a few days of no issues, with no changes to server config.

@HumnResources commented on GitHub (May 6, 2025): Bump. Confirm same issue. Managed to resolve it once before by reinstalling but that was after multiple attempts/versions. Double checked the token is valid and has access, just appears to not be passed through to the command. In both cases, my git auth failed after a few days of no issues, with no changes to server config.

GiteaMirror commented

2026-06-10 20:01:31 -05:00

@rVox-Dei commented on GitHub (May 10, 2025):

Bumping. Same issue. Running a self-hosted Gitlab instance and I've tried Deploy Keys, Deploy Tokens and Personal Access tokens with the same failing to authenticate response as above.

@rVox-Dei commented on GitHub (May 10, 2025): Bumping. Same issue. Running a self-hosted Gitlab instance and I've tried Deploy Keys, Deploy Tokens and Personal Access tokens with the same failing to authenticate response as above.

GiteaMirror commented

2026-06-10 20:01:32 -05:00

@ravxen commented on GitHub (May 16, 2025):

Bump. I got the same issue.
Funny thing is, that the personal access token from gitlab.com works, from my selfhosted gitlab not.

@ravxen commented on GitHub (May 16, 2025): Bump. I got the same issue. Funny thing is, that the personal access token from gitlab.com works, from my selfhosted gitlab not.

GiteaMirror commented

2026-06-10 20:01:32 -05:00

@lu1as commented on GitHub (May 16, 2025):

I was able to use a project access token (Role: Reporter, Scopes: read_repository) on my self-hosted GitLab instance as a workaround for now.

@lu1as commented on GitHub (May 16, 2025): I was able to use a project access token (Role: Reporter, Scopes: read_repository) on my self-hosted GitLab instance as a workaround for now.

GiteaMirror commented

2026-06-10 20:01:33 -05:00

@ravxen commented on GitHub (May 16, 2025):

I was able to use a project access token (Role: Reporter, Scopes: read_repository) on my self-hosted GitLab instance as a workaround for now.

What did you put in as a username?

@ravxen commented on GitHub (May 16, 2025): > I was able to use a project access token (Role: Reporter, Scopes: read_repository) on my self-hosted GitLab instance as a workaround for now. What did you put in as a username?

GiteaMirror commented

2026-06-10 20:01:33 -05:00

@lu1as commented on GitHub (May 16, 2025):

The name of the token. But I guess GitLab does not check the username for these types of tokens, that's why it works.

@lu1as commented on GitHub (May 16, 2025): The name of the token. But I guess GitLab does not check the username for these types of tokens, that's why it works.

GiteaMirror commented

2026-06-10 20:01:33 -05:00

@tullisar commented on GitHub (May 22, 2025):

I can confirm this happens using Atlassian Bitbucket. Personal access tokens generated for a user use the URL scheme :, and if you use the wrong username (in this case "token" gets used), Bitbucket denies the request. The username selected in the repository configuration isn't used at all for the clone command.

I also noticed (similar to others) that the token disappears entirely with certain characters. Specifically in my case a token had '/' characters in it. I escaped them in the Komodo configuration, which resulted in the token being passed in the command but I think the characters might need to be URL encoded. When I regenerated my token for one that didn't have a / character that worked (minus the username issue mentioned previously).

@tullisar commented on GitHub (May 22, 2025): I can confirm this happens using Atlassian Bitbucket. Personal access tokens generated for a user use the URL scheme <USER>:<TOKEN>, and if you use the wrong username (in this case "token" gets used), Bitbucket denies the request. The username selected in the repository configuration isn't used at all for the clone command. I also noticed (similar to others) that the token disappears entirely with certain characters. Specifically in my case a token had '/' characters in it. I escaped them in the Komodo configuration, which resulted in the token being passed in the command but I think the characters might need to be URL encoded. When I regenerated my token for one that didn't have a / character that worked (minus the username issue mentioned previously).

GiteaMirror commented

2026-06-10 20:01:34 -05:00

@Netruitus commented on GitHub (Jun 8, 2025):

I think it's quite related.
In my case not only token is the problem, but also for some reason Github tries to pull through http:
git clone http://token:<TOKEN>@github.com/Netruitus/project-c/repo-cache/github.com/Netruitus-project-c/main/latest -b main

Token and repo were checked, I could pull everything locally. I refreshed the config many times, it stays http. Re-created the stack too, didn't help.

@Netruitus commented on GitHub (Jun 8, 2025): I think it's quite related. In my case not only token is the problem, but also for some reason Github tries to pull through http: `git clone http://token:<TOKEN>@github.com/Netruitus/project-c/repo-cache/github.com/Netruitus-project-c/main/latest -b main` ![Image](https://github.com/user-attachments/assets/9f155bf0-49d5-4ddd-bc9a-12a2003b5398) Token and repo were checked, I could pull everything locally. I refreshed the config many times, it stays http. Re-created the stack too, didn't help.

GiteaMirror commented

2026-06-10 20:01:34 -05:00

@NickMckloski commented on GitHub (Aug 7, 2025):

A work around to use a deploy token from gitlab is to just give it the username "token". Other access tokens from github work regardless of the username, this seems to just be an issue with certain providers who are strictly checking the username.

@NickMckloski commented on GitHub (Aug 7, 2025): A work around to use a deploy token from gitlab is to just give it the username "token". Other access tokens from github work regardless of the username, this seems to just be an issue with certain providers who are strictly checking the username.

GiteaMirror commented

2026-06-10 20:01:35 -05:00

@tnelson-doghouse commented on GitHub (Aug 14, 2025):

For Bitbucket, the username needs to be "x-token-auth". So I guess we're stuck.

@tnelson-doghouse commented on GitHub (Aug 14, 2025): For Bitbucket, the username needs to be "x-token-auth". So I guess we're stuck.

GiteaMirror commented

2026-06-10 20:01:35 -05:00

@tnelson-doghouse commented on GitHub (Aug 14, 2025):

For those wondering, the faulty code is at 118ae9b92c/client/core/rs/src/entities/mod.rs (L504) .

If the line were changed from
Some(token) => format!("token:{token}@"),
...to...
Some(token) => format!("{username}:{token}@"),
... then that would probably work.

Until that happens, Komodo is useless for BiBucket users.

HTH,

@tnelson-doghouse commented on GitHub (Aug 14, 2025): For those wondering, the faulty code is at https://github.com/moghtech/komodo/blob/118ae9b92caf95ae0fdabe9f5984923af4c3bd9d/client/core/rs/src/entities/mod.rs#L504 . If the line were changed from ``` Some(token) => format!("token:{token}@"),``` ...to... ``` Some(token) => format!("{username}:{token}@"),``` ... then that would probably work. Until that happens, Komodo is useless for BiBucket users. HTH,

GiteaMirror commented

2026-06-10 20:01:35 -05:00

@tomazurro commented on GitHub (Aug 20, 2025):

As a workaround on self hosted git repositories one may define basic authentication and a user named token using the same password as was set as token for the user in komodo, since komodo requests urls of the form

https://token:<KOMODE_CHOSEN_USER_TOKEN>@git.domain.tld....

@tomazurro commented on GitHub (Aug 20, 2025): As a workaround on self hosted git repositories one may define basic authentication and a user named token using the same password as was set as token for the user in komodo, since komodo requests urls of the form https://token:<KOMODE_CHOSEN_USER_TOKEN>@git.domain.tld....

GiteaMirror commented

2026-06-10 20:01:36 -05:00

@mbecker20 commented on GitHub (Sep 1, 2025):

Hi, v1.19.2 is now out, and as per the release notes, Git Providers such as Bitbucket with particular <token>:<access_token> patterns in order to authenticate can now can include that part in with the Access Token. If not explicitly prefixed using :, it will default to token:<ACCESS_TOKEN>, making this change non-breaking for existing users.

Before closing, may I ask if there are any cases here which this feature does not fix?

@mbecker20 commented on GitHub (Sep 1, 2025): Hi, v1.19.2 is now out, and as per the release notes, Git Providers such as Bitbucket with particular `<token>:<access_token>` patterns in order to authenticate can now can include that part in with the Access Token. If not explicitly prefixed using `:`, it will default to `token:<ACCESS_TOKEN>`, making this change non-breaking for existing users. <img width="514" height="380" alt="Image" src="https://github.com/user-attachments/assets/0147e581-e32b-458b-8060-69e258715fc8" /> Before closing, may I ask if there are any cases here which this feature **does not fix**?

GiteaMirror commented

2026-06-10 20:01:36 -05:00

@matthieu-paturot commented on GitHub (Oct 15, 2025):

Hi,

I found a workaround for Bitbucket, in the "Token" field, I set :. Not sexy but it works.

@matthieu-paturot commented on GitHub (Oct 15, 2025): Hi, I found a workaround for Bitbucket, in the "Token" field, I set <USERNAME>:<TOKEN>. Not sexy but it works.

GiteaMirror commented

2026-06-10 20:01:37 -05:00

@AndreKR commented on GitHub (Oct 26, 2025):

Ok, with the username in the Token field, it now works with a GitLab deploy token. If the username goes into the "Token" field, what is the "Username"? An identifier for the account?

@AndreKR commented on GitHub (Oct 26, 2025): Ok, with the username in the Token field, it now works with a GitLab deploy token. If the username goes into the "Token" field, what is the "Username"? An identifier for the account?

GiteaMirror commented

2026-06-10 20:01:38 -05:00

@proton1k commented on GitHub (Jan 5, 2026):

Thanks @mbecker20 , your trick works for bitbucket.org!

@proton1k commented on GitHub (Jan 5, 2026): Thanks @mbecker20 , your trick works for bitbucket.org!

GiteaMirror commented

2026-06-10 20:01:38 -05:00

@mrVragec commented on GitHub (Apr 4, 2026):

Worked for me in github, just take care that token used in Komodo has correct permissions.

@mrVragec commented on GitHub (Apr 4, 2026): Worked for me in github, just take care that token used in Komodo has correct permissions. <img width="791" height="251" alt="Image" src="https://github.com/user-attachments/assets/c0584a81-e236-4e6a-a6a5-7efae183a7d8" />

GiteaMirror commented

2026-06-10 20:01:39 -05:00

@MDeca001 commented on GitHub (May 6, 2026):

Confirming on v2.1.2 with GitHub fine-grained PAT

Same symptom as the original report — the clone command shows https://token:@github.com/... with a completely empty password slot. The prefix syntax workaround introduced in v1.19.2 (<username>:<token> in the token field) does not resolve it on v2.1.2.

Environment

Komodo Core: v2.1.2 (ghcr.io/moghtech/komodo-core:2)
Auth method: GitHub fine-grained PAT, scoped to a single repo, Contents: Read
Provider configured via core.config.toml mounted at /config/config.toml

Provider config

[[git_providers]]
domain = "github.com"
https = true

[[git_providers.accounts]]
username = "<owner>"
token = "github_pat_..."   # also tried "<owner>:github_pat_..." — no change

Startup log confirms the provider parses correctly:

git_providers: [GitProvider { domain: "github.com", https: true,
  accounts: [ProviderAccount { username: "<owner>", token: "##############" }] }]

Sync resource (from `GetResourceSync` API)

"git_provider": "github.com",
"git_https": true,
"git_account": "<owner>",
"repo": "<owner>/<repo>",
"branch": "main"

GIT_TRACE evidence

With GIT_TRACE=1 and GIT_CURL_VERBOSE=1 set on the Core container:

trace: built-in: git clone https://token:@github.com/<owner>/<repo> ...
== Info: Server auth using Basic with user 'token'
== Info: [HTTP/2] [3] [authorization: Basic ]
=> Send header: Authorization: Basic 
HTTP/2 401
remote: Invalid username or token. Password authentication is not supported for Git operations.

The token slot in the URL is literally empty, and the Authorization: Basic header carries no base64 payload — Komodo is not substituting the token into the constructed URL at all.

What I ruled out

PAT validity: curl -H "Authorization: Bearer $TOKEN" https://api.github.com/repos/<owner>/<repo> returns 200.
Manual clone from inside the Core container with the exact token extracted from /config/config.toml: succeeds.
Stale credential helpers: no .git-credentials, no .netrc; git config --global --list and --system --list are empty inside the container.
Hidden whitespace / encoding in the username: od -c of the relevant line yields a clean M D e c a 0 0 1 \n.
Prefix workaround: token = "<owner>:github_pat_..." produces the identical https://token:@host/... URL.
Sync-specific vs. general: bug reproduces both with a [[resource_sync]] using inline git config and with a standalone [[repo]] resource — the failure is in the credential lookup or URL build path, not specific to syncs.

Workaround applied

Downgrading to v1.19.5 (km database v1-downgrade -y, then pin image to 1.19.5). Happy to run further diagnostics or test patches against v2.x if that helps narrow it down.

Update / resolution on v1.19.5 with the prefix workaround:

After downgrading from v2.1.2 to v1.19.5 the URL substitution works as designed — the clone command now contains the real token in the password slot (https://token:<token>@github.com/...) and the Authorization: Basic <base64> header is complete. So the v2.1.2 "token disappears entirely" behaviour is a separate regression that does not exist on v1.19.5.

However, GitHub still returns 401 Invalid username or token for fine-grained PATs specifically. GitHub's fine-grained PAT documentation requires the HTTP basic auth username to be the actual GitHub username (or the placeholder x-access-token). Komodo's hardcoded default username token doesn't satisfy that requirement — fine-grained PATs reject it. Classic PATs are more permissive about the username, which is probably why this hasn't been reported as a GitHub-specific case before (most GitHub users in this thread seem to be on classic PATs).

The v1.19.2 prefix workaround does resolve it on v1.19.5:

[[git_providers.accounts]]
username = "<github-username>"
token = "<github-username>:github_pat_..."   # prefix the token with the real username

With that change, the URL becomes https://<github-username>:github_pat_...@github.com/..., GitHub accepts it, and the clone succeeds.

Summary for anyone landing here from search:

v1.19.5 + classic PAT → works out of the box.
v1.19.5 + fine-grained PAT → needs the prefix workaround above.
v2.1.2 + either PAT type → does not work because the token isn't substituted into the URL at all (separate bug).

@MDeca001 commented on GitHub (May 6, 2026): ## Confirming on v2.1.2 with GitHub fine-grained PAT Same symptom as the original report — the clone command shows `https://token:@github.com/...` with a **completely empty password slot**. The prefix syntax workaround introduced in v1.19.2 (`<username>:<token>` in the token field) does **not** resolve it on v2.1.2. ### Environment - Komodo Core: **v2.1.2** (`ghcr.io/moghtech/komodo-core:2`) - Auth method: GitHub **fine-grained PAT**, scoped to a single repo, `Contents: Read` - Provider configured via `core.config.toml` mounted at `/config/config.toml` ### Provider config ```toml [[git_providers]] domain = "github.com" https = true [[git_providers.accounts]] username = "<owner>" token = "github_pat_..." # also tried "<owner>:github_pat_..." — no change ``` Startup log confirms the provider parses correctly: ``` git_providers: [GitProvider { domain: "github.com", https: true, accounts: [ProviderAccount { username: "<owner>", token: "##############" }] }] ``` ### Sync resource (from `GetResourceSync` API) ```json "git_provider": "github.com", "git_https": true, "git_account": "<owner>", "repo": "<owner>/<repo>", "branch": "main" ``` ### GIT_TRACE evidence With `GIT_TRACE=1` and `GIT_CURL_VERBOSE=1` set on the Core container: ``` trace: built-in: git clone https://token:@github.com/<owner>/<repo> ... == Info: Server auth using Basic with user 'token' == Info: [HTTP/2] [3] [authorization: Basic ] => Send header: Authorization: Basic HTTP/2 401 remote: Invalid username or token. Password authentication is not supported for Git operations. ``` The token slot in the URL is literally empty, and the `Authorization: Basic` header carries no base64 payload — Komodo is not substituting the token into the constructed URL at all. ### What I ruled out - **PAT validity**: `curl -H "Authorization: Bearer $TOKEN" https://api.github.com/repos/<owner>/<repo>` returns `200`. - **Manual clone from inside the Core container** with the exact token extracted from `/config/config.toml`: succeeds. - **Stale credential helpers**: no `.git-credentials`, no `.netrc`; `git config --global --list` and `--system --list` are empty inside the container. - **Hidden whitespace / encoding in the username**: `od -c` of the relevant line yields a clean `M D e c a 0 0 1 \n`. - **Prefix workaround**: `token = "<owner>:github_pat_..."` produces the identical `https://token:@host/...` URL. - **Sync-specific vs. general**: bug reproduces both with a `[[resource_sync]]` using inline git config and with a standalone `[[repo]]` resource — the failure is in the credential lookup or URL build path, not specific to syncs. ### Workaround applied Downgrading to v1.19.5 (`km database v1-downgrade -y`, then pin image to `1.19.5`). Happy to run further diagnostics or test patches against v2.x if that helps narrow it down. **Update / resolution on v1.19.5 with the prefix workaround:** After downgrading from v2.1.2 to v1.19.5 the URL substitution works as designed — the clone command now contains the real token in the password slot (`https://token:<token>@github.com/...`) and the `Authorization: Basic <base64>` header is complete. So the v2.1.2 "token disappears entirely" behaviour is a separate regression that does not exist on v1.19.5. However, GitHub still returns `401 Invalid username or token` for **fine-grained PATs** specifically. GitHub's fine-grained PAT documentation requires the HTTP basic auth username to be the actual GitHub username (or the placeholder `x-access-token`). Komodo's hardcoded default username `token` doesn't satisfy that requirement — fine-grained PATs reject it. Classic PATs are more permissive about the username, which is probably why this hasn't been reported as a GitHub-specific case before (most GitHub users in this thread seem to be on classic PATs). The v1.19.2 prefix workaround does resolve it on v1.19.5: ```toml [[git_providers.accounts]] username = "<github-username>" token = "<github-username>:github_pat_..." # prefix the token with the real username ``` With that change, the URL becomes `https://<github-username>:github_pat_...@github.com/...`, GitHub accepts it, and the clone succeeds. Summary for anyone landing here from search: - v1.19.5 + classic PAT → works out of the box. - v1.19.5 + fine-grained PAT → needs the prefix workaround above. - v2.1.2 + either PAT type → does not work because the token isn't substituted into the URL at all (separate bug).

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/komodo#22122

[GH-ISSUE #387] Git Clone Repo tries to authenticate with "token" and "<TOKEN>" #22122

Confirming on v2.1.2 with GitHub fine-grained PAT

Environment

Provider config

Sync resource (from GetResourceSync API)

GIT_TRACE evidence

What I ruled out

Workaround applied

Sync resource (from `GetResourceSync` API)