Context

Gitea's action.yml currently pins the external action anthropics/claude-code-base-action@v0.0.63 to run Claude. That external repo has been frozen since Aug 2025 — v0.0.63 is the latest release. Upstream's active base-action work now happens inside the monorepo subdirectory ./base-action/ (Agent SDK ^0.2.117, as of v1.0.103).

Gitea's ./base-action/ directory is kept in sync with upstream via the routine merge flow (we already pick up its version bumps). But we don't use it — the Run Claude Code step still invokes the external pinned action.

Why switch

Switching to uses: ./base-action would unlock these action inputs that are currently plumbed as env vars but inert on Gitea:

• show_full_output — full JSON output dump
• plugins + plugin_marketplaces — Claude Code plugin install
• display_report — GitHub Step Summary rendering

Why not rushed

This is architecturally different, not a patch bump. The local ./base-action/ has a different input shape:

Switching requires:

• Refactor src/entrypoints/prepare.ts to construct a claude_args string from Gitea's existing individual inputs.
• Rewrite the Run Claude Code step in action.yml from uses: anthropics/claude-code-base-action@v0.0.63 → uses: ./base-action.
• Likely add a compat shim for Gitea users whose workflows pass the individual inputs directly (otherwise they break).
• Commit to keeping ./base-action/ in sync with upstream on future merges (already happening de facto, but would become load-bearing).

Estimated scope: ~50–100 lines of code + tests + migration notes.

When to prioritize

Per codex-cli recommendation during the v1.0.103 sync decision (commit 0542de9):

B is worthwhile, but it is not a same-day follow-on to an upstream patch bump. It changes execution shape, expands the compatibility surface, and creates migration/maintenance obligations for existing Gitea workflows. That is the kind of change a conservative maintainer should do intentionally, behind a separate branch/PR, with regression coverage and a compatibility policy.

Flip the switch when one of the triggers fires:

• A real user asks for show_full_output / plugins / display_report on Gitea
• Upstream lands a critical fix only in ./base-action/ (not backported to v0.0.63)
• Upstream deprecates or publishes a breaking v0.0.64 that we can't take
• Gitea sync merges start routinely carrying large ./base-action/ deltas we're ignoring

Acceptance criteria (when executed)

• ./base-action/ used via uses: ./base-action in action.yml
• claude_args construction in prepare.ts produces same CLI invocation as current pinned-action path (regression tests)
• Existing Gitea workflow inputs (max_turns, timeout_minutes, model, mcp_config, system_prompt, append_system_prompt, fallback_model) still work — either passed through or documented migration path
• show_full_output, plugins, plugin_marketplaces, display_report inputs become live (currently stubbed as env vars)
• Existing test suite passes + new tests for claude_args construction
• CHANGELOG / migration note for Gitea users

Related

• Merge audit / port work: commits 19d15d0 (merge) → 0542de9 (parity with v1.0.103)
• OIDC exchange port: blocked upstream (Native OIDC Token for workload identity federation go-gitea/gitea#33681, #36988) — separate future work
• classify_inline_comments port: needs Gitea-native rewrite (reviews-grouped semantics) — separate future work