fix: pin bun runtime config and improve log hygiene

[ashwin-ant]

• Pin --config, --tsconfig-override, and --no-env-file on the three bun run entrypoints so bun resolves runtime config from the action directory instead of the workspace
• Register the OIDC-exchanged app token with core.setSecret
• Omit extraArgs from the SDK options debug log alongside env
• Add CLAUDE.md, CLAUDE.local.md, and .husky to the config-restore list
• Prettier line-wrap in base-action/test/parse-sdk-options.test.ts (drift from fix: strip shell comment lines before parsing claude_args #1055)

Tests, typecheck, and format all pass.

[claude]

🔴 The OIDC token obtained via getOidcToken() is never masked with core.setSecret(), while this PR adds core.setSecret(appToken) for the exchanged app token. Although the OIDC token is not currently logged in any code path, the PR establishes an inconsistent masking pattern — add core.setSecret(oidcToken) immediately after line 138 to apply the same hygiene to the upstream bearer credential.

Extended reasoning...

What the bug is: The setupGitHubToken() function obtains an OIDC JWT token from GitHub Actions at line 138 (const oidcToken = await retryWithBackoff(() => getOidcToken())) and then uses it to exchange for an app token. This PR adds core.setSecret(appToken) at line 151 to mask the exchanged app token in CI logs. However, the oidcToken itself — a GitHub Actions JWT bearer credential with audience claude-code-github-action — is never passed to core.setSecret(), meaning it is not registered as a secret and would appear in plaintext if it ever surfaced in logs.

The specific code path: The OIDC token flows from getOidcToken() into retryWithBackoff(), then into exchangeForAppToken() where it is placed in the Authorization: Bearer ${oidcToken} header. The PR masks the downstream credential (appToken) but not the upstream credential (oidcToken).

Why existing code does not prevent it: The current code does not log the OIDC token directly — retryWithBackoff logs only lastError.message (not full error objects or arguments), and error paths in exchangeForAppToken throw Error objects with plain message strings derived from the server response, not from the token value. So the token is not actively leaking today.

What the impact would be: While not an active leak in current code, the OIDC token is still a valid bearer credential (short-lived but non-trivially scoped to the action's audience). More importantly, the PR explicitly establishes the pattern of calling core.setSecret() for sensitive tokens — applying it to the downstream token but not the upstream one is an inconsistency that could cause confusion. If any future logging, debug output, or error-handling change inadvertently surfaces oidcToken, it would appear in plaintext in publicly-visible GitHub Actions logs. GitHub's own Actions toolkit documentation recommends masking tokens returned by core.getIDToken() immediately after retrieval.

How to fix it: Add core.setSecret(oidcToken) immediately after line 138, right after the console.log('OIDC token successfully obtained') statement. This completes the security hygiene pass the PR is already performing.

Step-by-step proof of the inconsistency: (1) setupGitHubToken() calls getOidcToken() and gets back a JWT string. (2) This JWT is stored in oidcToken at line 138 — no core.setSecret() call is made. (3) oidcToken is passed to exchangeForAppToken() where it becomes the Authorization header value. (4) exchangeForAppToken() returns appToken. (5) The PR adds core.setSecret(appToken) at line 151. (6) Result: appToken is masked in GitHub Actions logs; oidcToken is not. If any log statement were added to print oidcToken (e.g., a debug log in exchangeForAppToken), the full JWT would appear unredacted.

[claude]

🟣 The positional entrypoint path argument is unquoted in all three bun run steps: run ${GITHUB_ACTION_PATH}/src/entrypoints/run.ts — if GITHUB_ACTION_PATH contains spaces (possible on self-hosted runners), bash word-splitting will break the command. This is a pre-existing issue that this PR makes more visible by adding properly double-quoted --config and --tsconfig-override flags alongside the unquoted path; fix by wrapping the path: run "${GITHUB_ACTION_PATH}/src/entrypoints/run.ts".

Extended reasoning...

The unquoted shell expansion run ${GITHUB_ACTION_PATH}/src/entrypoints/run.ts is present in all three bun entrypoint steps (lines ~232, ~332, ~346 of action.yml). When bash processes this command, it performs word-splitting on unquoted variable expansions. If GITHUB_ACTION_PATH contains a space — for example /my runner/_actions/org/repo/v1 on a self-hosted runner — bash will split it into separate tokens, and bun will receive run, /my, runner/... as distinct arguments rather than a single file path, causing a file-not-found error.

The code path that triggers the bug: any self-hosted GitHub Actions runner whose configured path contains whitespace. The environment variable GITHUB_ACTION_PATH is set by the Actions runner to the directory of the checked-out action. While GitHub-hosted runners use /home/runner/work/_actions/... (no spaces), enterprise self-hosted runners can be configured with arbitrary paths.

The existing code fails to prevent this because the --config and --tsconfig-override flags added by this PR are correctly quoted (--config="${GITHUB_ACTION_PATH}/bunfig.toml"), demonstrating that the author was aware of proper quoting, but the final positional argument was overlooked. The old single-line invocation had the same issue and was never fixed.

The practical impact is low: GitHub-hosted runners never have spaces in GITHUB_ACTION_PATH, and most self-hosted runners follow similar conventions. However, the inconsistency is now more prominent — three properly-quoted flags sit right above an unquoted path argument, which could mislead reviewers into thinking the path is safe.

This is a pre-existing issue not introduced by this PR. The original bun run ${GITHUB_ACTION_PATH}/src/entrypoints/run.ts had the same unquoted expansion. The PR touched these lines and could have fixed it incidentally when reformatting to multi-line, but did not introduce the problem.

Step-by-step proof: (1) A self-hosted runner is configured with a path containing a space, e.g. /my runners/actions. (2) The runner sets GITHUB_ACTION_PATH=/my runners/actions/org/repo@v1. (3) bash executes bun --no-env-file --config="..." --tsconfig-override="..." run ${GITHUB_ACTION_PATH}/src/entrypoints/run.ts. (4) After word-splitting, bun receives: arg0=run, arg1=/my, arg2=runners/actions/org/repo@v1/src/entrypoints/run.ts. (5) Bun tries to find a file named /my — it does not exist — and exits with an error. Fix: change to run "${GITHUB_ACTION_PATH}/src/entrypoints/run.ts" in all three steps.

[maxired]

In our repo, we do commit the .husky files, but not the hook setup in themself.
with this setup, we need to rerun npx husky to reinstall the hooks, otherwise, our pre commit hook do not run.
this broke previous behavior