fix: Forgejo API tokens rejected for git HTTP push — agents must use password auth #361

New issue

Closed

opened 2026-04-07 16:42:36 +00:00 by dev-bot · 0 comments

dev-bot commented

2026-04-07 16:42:36 +00:00

Collaborator

Problem

Forgejo 11.x rejects API tokens (created via POST /api/v1/users/{user}/tokens with scopes ["all"]) for git HTTP push operations:

git push http://dev-bot:<api-token>@forgejo:3000/disinto-admin/disinto.git
remote: Credentials are incorrect or have expired.

The same token works for all Forgejo REST API calls. Git clone also works with the token. Only git push is rejected.

Password-based HTTP auth works:

git push http://dev-bot:<password>@forgejo:3000/disinto-admin/disinto.git
Everything up-to-date

This forces all agents to use password auth for git operations, which is less secure and requires storing plaintext passwords.

Root cause

Forgejo may require specific token scopes for git write operations that the "all" scope doesn't cover, or there's a bug in Forgejo 11's git HTTP auth handler for API tokens.

Relevant: https://codeberg.org/forgejo/forgejo/issues/2809

Current workaround

Agent git remotes use password auth: http://dev-bot:@forgejo:3000/...

Proposed fix

Investigate Forgejo 11 token scopes for git push. The fix is either:

Create tokens with the correct scope that enables git push (if such a scope exists)
Use application tokens instead of user tokens (Forgejo supports app-level tokens)
Or accept password auth and ensure disinto init sets up git remotes with password auth consistently

The git remote setup happens in:

docker/agents/entrypoint.sh (repo clone on first start)
docker/agents/entrypoint-llama.sh (repo clone)
dev/dev-agent.sh (worktree setup, inherits remote from base repo)
lib/worktree.sh (worktree operations)

Affected files

bin/disinto or lib/forge-setup.sh (investigate correct token scope during init)
docker/agents/entrypoint.sh (git remote URL setup)
docker/agents/entrypoint-llama.sh (git remote URL setup)

Acceptance criteria

Git push from inside agent containers works with token-based auth (preferred) or password auth is consistently configured
No manual intervention needed after container restart
disinto init sets up the correct auth method

## Problem Forgejo 11.x rejects API tokens (created via POST /api/v1/users/{user}/tokens with scopes ["all"]) for git HTTP push operations: git push http://dev-bot:<api-token>@forgejo:3000/disinto-admin/disinto.git remote: Credentials are incorrect or have expired. The same token works for all Forgejo REST API calls. Git clone also works with the token. Only git push is rejected. Password-based HTTP auth works: git push http://dev-bot:<password>@forgejo:3000/disinto-admin/disinto.git Everything up-to-date This forces all agents to use password auth for git operations, which is less secure and requires storing plaintext passwords. ## Root cause Forgejo may require specific token scopes for git write operations that the "all" scope doesn't cover, or there's a bug in Forgejo 11's git HTTP auth handler for API tokens. Relevant: https://codeberg.org/forgejo/forgejo/issues/2809 ## Current workaround Agent git remotes use password auth: http://dev-bot:<password>@forgejo:3000/... ## Proposed fix Investigate Forgejo 11 token scopes for git push. The fix is either: 1. Create tokens with the correct scope that enables git push (if such a scope exists) 2. Use application tokens instead of user tokens (Forgejo supports app-level tokens) 3. Or accept password auth and ensure disinto init sets up git remotes with password auth consistently The git remote setup happens in: - docker/agents/entrypoint.sh (repo clone on first start) - docker/agents/entrypoint-llama.sh (repo clone) - dev/dev-agent.sh (worktree setup, inherits remote from base repo) - lib/worktree.sh (worktree operations) ## Affected files - bin/disinto or lib/forge-setup.sh (investigate correct token scope during init) - docker/agents/entrypoint.sh (git remote URL setup) - docker/agents/entrypoint-llama.sh (git remote URL setup) ## Acceptance criteria - [ ] Git push from inside agent containers works with token-based auth (preferred) or password auth is consistently configured - [ ] No manual intervention needed after container restart - [ ] disinto init sets up the correct auth method