Two integration tests fail when run inside act_runner because the
job container shares the host's docker socket — networks created on
the host daemon aren't always visible in-process, and ports published
by sibling containers aren't reachable on the job's 127.0.0.1.
Skip them when GITEA_ACTIONS=true. Document the limitation in
docs/ci.md as a follow-up to revisit.
Assisted-by: Claude Code
Add a Gitea Actions test-status badge plus a short README "CI" section
covering how to read the check and what to do when it's red. Capture
the (out-of-tree) branch-protection rule on `main` in docs/ci.md so
the gate that requires the test check is reproducible from the repo
alone — covers both the Gitea UI path and the equivalent API call.
Refs: PRD 0002
Assisted-by: Claude Code
Investigates whether the Gitea `tea` CLI can be authenticated via a
header-injecting proxy so the token never enters the container — even as
an env var. Parallels the OAuth-token research note. Recommends an
in-container root-owned reverse proxy as the lowest-friction shape, and
flags the unavoidable tradeoff that the agent retains the token's full
API scope (no exfil ≠ no harm).
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Walks the current `docker run -e CLAUDE_CODE_OAUTH_TOKEN` flow, why claude
can read the token trivially via its Bash tool, why no Linux primitive
hides an env var from its own process, and why a root-owned localhost
auth-injecting reverse proxy (paired with an egress allowlist) is the
realistic mitigation. Documents `ANTHROPIC_BASE_URL` caveats (SSE,
header passthrough, issue #36998, out-of-band traffic).
didericis