openab-claude:0.8.2 — CLAUDE_CODE_OAUTH_TOKEN exported by /opt/start-openab.sh no longer reaches claude-agent-acp (regressed by CLAUDE_CODE_VERSION bump 2.1.116 → 2.1.124)

[STom1c]

Summary

After upgrading from openab-claude:0.8.1 to 0.8.2, every Claude reply via claude-agent-acp returns Server Error (code: -32000) Authentication required — even though OPENAB_AUTH_TOKEN is correctly set as a long-lived OAuth token (sk-ant-oat01-…) and the wrapper /opt/start-openab.sh correctly maps it to CLAUDE_CODE_OAUTH_TOKEN.

The same env-var configuration worked on 0.8.1 for 2+ days. The only auth-relevant change in v0.8.1...v0.8.2 is Dockerfile.claude bumping ARG CLAUDE_CODE_VERSION=2.1.116 → 2.1.124, so this looks like an upstream Claude Code regression in env-var pickup across the wrapper's su -p user-switch boundary, surfaced through the openab image bump.

Environment

• Image: ghcr.io/openabdev/openab-claude:0.8.2 (reproduced on :latest while latest resolved to 0.8.2)
• Deployment: Zeabur BYOC k3s, single replica
• Container user: node (UID 1000)
• Wrapper: stock /opt/start-openab.sh from the image (verified identical to 0.8.1 via kubectl exec ... cat)
• Pinned subcomponent versions inside 0.8.2 per its Dockerfile.claude:
  • @agentclientprotocol/claude-agent-acp@0.29.2 (unchanged from 0.8.1)
  • @anthropic-ai/claude-code@2.1.124 (was 2.1.116 on 0.8.1)

Reproduction

1. Deploy openab-claude:0.8.2 with these env vars only:
   • OPENAB_AUTH_TOKEN = a long-lived OAuth token from claude setup-token (format sk-ant-oat01-…)
   • DISCORD_BOT_TOKEN, OPENAB_ALLOWED_CHANNELS, OPENAB_MAX_SESSIONS, etc. (no CLAUDE_CODE_OAUTH_TOKEN)
2. Bot connects to Discord cleanly. Logs show:

   openab: discord bot connected user=<bot>
   openab::acp::connection: spawning agent cmd="claude-agent-acp"
   openab::acp::connection: initialized agent="@agentclientprotocol/claude-agent-acp" load_session=true
   openab::acp::connection: session created session_id=…
   

3. @bot ping in the allowed channel.
4. Bot replies with: ⚠️ Server Error (code: -32000) Authentication required.

Expected behavior

The wrapper case "$OPENAB_AUTH_TOKEN" in sk-ant-oat*) export CLAUDE_CODE_OAUTH_TOKEN="$OPENAB_AUTH_TOKEN" ;; should make the OAuth token available to claude-agent-acp after exec su -p -s /bin/sh node -c "exec openab run …". This worked on 0.8.1.

Actual behavior

claude-agent-acp (or the Claude Code SDK it uses) does not see CLAUDE_CODE_OAUTH_TOKEN and returns Authentication required. Inspecting /proc/1/environ of the running pod (and kubectl exec env) shows OPENAB_AUTH_TOKEN is present (it's a Docker ENV) but CLAUDE_CODE_OAUTH_TOKEN is not — i.e., the wrapper's export does not survive into the agent process tree.

Evidence the regression is in 0.8.2 specifically

ReplicaSet history from a single Zeabur deployment (k3s kubectl get rs -o json), same env-var set throughout (no CLAUDE_CODE_OAUTH_TOKEN, just OPENAB_AUTH_TOKEN):

Created (UTC)	Image	CLAUDE_CODE_OAUTH_TOKEN in spec	Bot worked?
2026-04-30 10:09–10:18 (×4 RSes, Phase 3)	openab-claude:0.8.1	❌ no	✅ yes — bot live for 2+ days
2026-05-02 02:25	openab-claude:0.8.2	❌ no	❌ failing
2026-05-02 03:52 → 2026-05-03 03:48 (×5 RSes)	openab-claude:latest (then 0.8.2)	❌ no	❌ failing
2026-05-03 03:51 onward	openab-claude:0.8.1 (rolled back) + CLAUDE_CODE_OAUTH_TOKEN direct env var added	✅ yes	✅ working

The wrapper script /opt/start-openab.sh is byte-identical between the 0.8.1 and 0.8.2 images we ran. The 0.8.1...0.8.2 repo diff confirms the only auth-touching change is the CLAUDE_CODE_VERSION bump in Dockerfile.claude:

-ARG CLAUDE_CODE_VERSION=2.1.116
+ARG CLAUDE_CODE_VERSION=2.1.124

Workaround

Set CLAUDE_CODE_OAUTH_TOKEN as a direct container env var (not via the wrapper export), with the same value as OPENAB_AUTH_TOKEN. With both env vars in the deployment spec, 0.8.2 should also work — though I have not yet redeployed 0.8.2 with the workaround to confirm (currently pinned to 0.8.1 for stability).

Suggested fix in openab-claude image

Change /opt/start-openab.sh to either:

• Use su -m (preserve full environment) instead of su -p (preserves only HOME/USER/SHELL/LOGNAME on Alpine BusyBox), or
• Pass the token explicitly to the su command line, e.g.:

  exec su -p -s /bin/sh node -c "CLAUDE_CODE_OAUTH_TOKEN='$CLAUDE_CODE_OAUTH_TOKEN' exec openab run --config '$CONFIG_FILE'"

This restores compatibility with the new Claude Code version's stricter env-var lookup at SDK init.

Additional context

• Reproduced on Zeabur (BYOC k3s on Linux/amd64). Likely affects any deployment where the openab-claude wrapper script is the entrypoint.
• Confirmed the OAuth token itself is valid: running CLAUDE_CODE_OAUTH_TOKEN=$OPENAB_AUTH_TOKEN claude -p hello directly inside the pod returns a normal Claude reply. The break is specifically in how claude-agent-acp (driven by the bumped Claude Code SDK) resolves the env var when launched through the wrapper.

[chaodu-agent]

Hi @STom1c — thanks for the detailed report!

After reviewing the official Dockerfile.claude, we noticed that /opt/start-openab.sh is not provided by the OpenAB GitHub repo. The official entrypoint is:

ENTRYPOINT ["tini", "--"]
CMD ["openab", "run", "-c", "/etc/openab/config.toml"]

There is no wrapper script, no su -p user-switch, and no OPENAB_AUTH_TOKEN → CLAUDE_CODE_OAUTH_TOKEN mapping in the official image. The container runs directly as USER node.

The /opt/start-openab.sh wrapper and the su -p env-var issue you described likely originate from your deployment platform (Zeabur). Could you please report or cross-link this issue to the Zeabur Discord channel for visibility from the Zeabur maintainers?

That said, the Claude Code SDK bump (2.1.116 → 2.1.124) may still have changed env-var lookup behavior — but the root cause of the auth failure in your setup appears to be platform-specific rather than an OpenAB bug.

[canyugs]

Hi @STom1c — thanks for the detailed report.

We've tested this on a Zeabur-managed environment with the same setup (openab-claude:0.8.2, Claude Code 2.1.124, the same /opt/start-openab.sh wrapper) and confirmed that su -p correctly passes the exported CLAUDE_CODE_OAUTH_TOKEN / ANTHROPIC_API_KEY to the openab process. The service runs normally with no authentication errors.

Key details from our test environment:

• OS: Debian GNU/Linux 12 (bookworm)
• su version: util-linux 2.38.1 (su -p fully preserves environment)
• PID 1: root (runs the wrapper script)
• PID 9 (openab): node user, env vars correctly inherited

Since you mentioned you're on Zeabur BYOC k3s, could you share a bit more about your environment?

1. What base OS / container runtime is your k3s node running? (e.g., Alpine-based k3s, Ubuntu, etc.)
2. Are there any Pod Security Policies, Security Contexts, or seccomp profiles applied to the namespace?
3. Does your k3s setup override the container's /usr/bin/su (e.g., BusyBox su instead of util-linux)?

On standard Zeabur infrastructure, su -p (util-linux on Debian) preserves all exported vars. But on Alpine-based or BusyBox environments, su -p only preserves a subset (HOME/USER/SHELL), which would explain the behavior you're seeing.

In the meantime, your workaround (setting CLAUDE_CODE_OAUTH_TOKEN as a direct env var in the deployment spec) is the correct approach for environments where su -p doesn't fully preserve the environment.