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

name, description

name	description
gitea-token-from-http-credential-store	Extract the Dankclaw Gitea token from ~/.config/secrets/gitea (it is the URL password, not key=value lines) for API calls, and diagnose the silent empty-token trap that makes public-repo reads pass while writes fail.

The Gitea credential store line on Frank's boxes is http (not https) with a percent-encoded port, and the token is the URL password — there are NO username=/password= lines:

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)
echo "tok len ${#tok}"          # must be 40 — assert before any call
cfg=$(mktemp); chmod 600 "$cfg"; printf 'header = "Authorization: token %s"\n' "$tok" > "$cfg"
curl -s -K "$cfg" http://192.168.0.143:3000/api/v1/<path>
rm -f "$cfg"                    # in the SAME session: the file holds a live token

git credential-store --file … fill answers EMPTY — do not debug it

Tried 2026-10-21 while opening dank/command-center PR #61: the obvious extraction

printf 'protocol=http\nhost=192.168.0.143\nport=3000\n\n' | git credential-store --file ~/.config/secrets/gitea fill

prints nothing, with no error. Not permissions, not a wrong path: the stored line encodes the port inside the host field (@192.168.0.143%3a3000), so a host=+port= query can never match it. Add path= or drop port= and it still answers empty. Read the file with sed (recipe above) and move on — the chain TOKEN=$(…) && [ -n "$TOKEN" ] && … fails silently at the test, which reads like a curl failure because the && hides which link broke.

The silent-empty-token trap (bit 2026-10-21, cost a debug detour)

An awk -F= '/^username=/{...}' parse of this file yields tok="" silently — and reads still appear to work when the repo is public: dank/serverAppConfigs and dank/command-center return real issue/label data unauthenticated, so every census "passes" until the first write (issue comment, label, PR create/merge) fails with {"message":"token is always required"}-style errors or 404s (private repos 404 on an empty token — that is an auth problem, NOT a missing repo).

• echo "tok len ${#tok}" (must be 40) before believing ANY API result — reads included.
• Prove auth once per session: GET /api/v1/user → "login":"dank".
• curl -s -K <600-perm file> carrying header = "Authorization: token $tok" — never -H on argv (/proc/<pid>/cmdline is world-readable; this leaked an HF token once).
• jq -n --arg t … --arg h … --arg b "$(/bin/cat /tmp/pr.md)" '{…}' — $(cat file) gets optimised away in this harness, so use --rawfile b /tmp/pr.md instead.

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
• Merge writes need form-encoded fields, not JSON — see gitea-pr-api-cycle.
• 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.