Files
command-center/agent/managed-skills/gitea-token-from-http-credential-store/SKILL.md
T

1.7 KiB
Raw Blame History

name, description
name description
gitea-token-from-http-credential-store Extract the Dankclaw Gitea token from ~/.config/secrets/gitea for API calls to PRIVATE repos, and diagnose the empty-token 404 that looks like a missing repo.

The Gitea credential store line on Frank's boxes is http (not https) with a percent-encoded port:

http://dank:<40-char-token>@192.168.0.143%3a3000

Extraction that actually works

tok=$(sed -nE 's#^[a-z]+://[^:]+:([^@]+)@.*#\1#p' ~/.config/secrets/gitea | head -1)
curl -s -H "Authorization: token $tok" http://192.168.0.143:3000/api/v1/<path>

Common wrong pattern (silent failure): an awk/grep anchored on https:// or on @192.168.0.143: matches nothing, leaving tok="" — verify with echo "tok len ${#tok}" before believing any API result.

The 404 trap

dank/command-center is public: an empty token still returns real issue data. dank/dankvoice is private: the same empty token returns 404 on /api/v1/repos/<owner>/<repo> and {}-shaped bodies (title: undefined) on issues. A 404 with a zero-length token is an auth problem, NOT a missing repo — confirm by printing the token length first, then re-check.

Other notes

  • git credential fill fails headless here (could not read Username … terminal prompts disabled); read the store file directly instead.
  • Never print the token: mask when inspecting the file — sed -E 's#(://[^:]+:)[^@]+@#\1REDACTED@#' ~/.config/secrets/gitea
  • Issue/PR numbers are per repo: dank/dankvoice #8–#11 (refactor, hardening, AbortError fix, menu defects) are unrelated to dank/command-center #8–#11 (SDLC, trunk-law). Read the body from the repo the work targets before referencing an issue in a commit message.