[BUG] Claude Tag: editing a custom connection (Rotate secret / edit allowed hosts) silently stops Agent Proxy attaching the credential; delete+recreate with identical config works

Surface

Claude Tag (Slack) admin console — claude.ai/admin-settings/claude-tag → Access bundle → Credentials → custom connection ("Connect another tool"), and the Agent Proxy credential injection it configures.

Summary

Mutating an existing custom connection — via Rotate secret or by editing its allowed hosts — causes Agent Proxy to stop attaching the connection's credential to requests. Requests to the connection's allowed host still leave the sandbox (egress works), but arrive at the target API with no Authorization header at all. Deleting the connection and recreating it with the secret entered at creation time, same values otherwise, restores correct behavior immediately.

Reproduced 3× on 2026-07-16 (~21:00 UTC through 2026-07-17 ~00:30 UTC), from both desktop and mobile console, with independently verified-valid replacement tokens each time.

Setup

• Custom HTTP connection: credential type Bearer (Atlassian scoped service-account API token), Allowed websites api.atlassian.com
• Bundle attached to a single Slack channel; no other bundles carrying Atlassian credentials or domain entries anywhere in the org (verified); no global/inherited bundles
• Fresh Slack top-level threads used for every test (to rule out stale session state)

Repro

1. Create the connection fresh with the secret in the create form → works. Verified two ways: GET https://api.atlassian.com/ex/jira/{cloudId}/rest/api/3/myself returns 200 with the service-account identity, and an https://httpbin.org/headers echo (host temporarily added to allowed websites) shows the exact header arriving: Bearer, correct 192-char credential, correct prefix/suffix.
2. Use ⋮ → Rotate secret on that working connection with a new, valid token (also exercised: editing the connection's allowed-hosts list) → from that point, every request to the allowed host arrives with no Authorization header. Atlassian returns 401 Client must be authenticated to access this resource / WWW-Authenticate: OAuth. During an equivalent broken state earlier in the day, the httpbin echo confirmed the header is entirely absent — not malformed, absent.
3. At the same timestamps, the same replacement token used directly via curl (Authorization: Bearer … to the same URL) returns 200 — the token is valid; only the proxied path loses the credential.
4. Delete the connection (or the whole bundle) and recreate it with identical values, secret entered at creation → works again immediately (200 via proxy, correct header via echo).

The console gives no error at any point — the edit appears to save successfully, and the write-only secret field makes the broken state invisible to the admin. The failure only surfaces as opaque 401s from the target API.

Expected

Rotating a secret or editing allowed hosts on a connection should leave credential injection working (that's the documented purpose of Rotate secret), or fail loudly in the console if the update can't be applied.

Impact

• Routine credential rotation — a security best practice the product itself encourages — silently breaks the integration until the admin discovers delete+recreate by trial and error.
• Cost us most of a working day: the broken state is indistinguishable from a bad token, a scope problem, or a bundle-attachment problem from the outside.

Timeline evidence (2026-07-16, UTC)

| Time | Action | Proxied result | Same token via curl |
|---|---|---|---|
| ~20:55 | Connection created fresh with secret | 200, authenticated | 200 |
| ~21:55 | Secret replaced on existing connection (desktop) | 401, no credential attached | 200 |
| ~22:30 | Secret re-entered again on existing connection | 401, no credential attached | 200 |
| ~23:47 | Connection deleted + recreated, secret at creation | 200; header verified byte-perfect via httpbin echo; writes work | 200 |
| ~00:20 (+1d) | Rotate secret with new valid token + allowed-hosts edit (httpbin removed) | 401, no credential attached | 200 (verified ~00:35) |

Possibly related

• #76212 — Claude Tag bundle Domains/credential allow-layers never reaching session egress (different defect: that one blocks egress; here egress works and only credential injection is lost after an edit) — same Tag connection/allow-layer subsystem.

🤖 Generated with Claude Code

https://claude.ai/code/session_01MtKV6u4jKjZiWuKTKHufJ2