[BUG] Claude in Chrome v1.0.70: Infinite OAuth retry loop on persistent 403 causes side panel flicker and forced logout

Status Fixed / completed
Maintainer reply None cached
Activity 13 comments · opened May 8, 2026 · closed May 9, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

Title

[BUG] Claude in Chrome v1.0.70: Infinite OAuth retry loop on
persistent 403 causes side panel flicker and forced logout

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet

(related but distinct from #29628, #34176 which involve scope errors
in different flows)

  • [x] This is a single bug report
  • [x] I am using the latest version of Claude in Chrome (v1.0.70)

Summary

The Claude in Chrome side panel flickers periodically (~every 10–20s)
and eventually forces a redirect to login, wiping all conversation
context. Network analysis (HAR) reveals an infinite retry loop: the
extension obtains a fresh OAuth token, attempts to upgrade a WebSocket
to bridge.claudeusercontent.com, receives a non-transient 403 error,
and immediately retries — repeatedly, indefinitely.

The server explicitly marks the error as transient: false, yet the
extension treats it as recoverable and re-attempts on every cycle.

Severity

🔴 High — Active sessions interrupted unpredictably; conversation
history permanently lost; reproduces consistently for affected accounts;
extension is unusable in this state.

Evidence (from HAR capture, 5-minute window)

In a 5-minute capture (17:43:24 → 17:48:25), 116 network requests
were recorded with the following pattern repeating ~25 times:

\\\
loop:
POST https://platform.claude.com/v1/oauth/token → 200 OK
WS wss://bridge.claudeusercontent.com/chrome/<bridge_id>
send: { "type": "connect",
"client_type": "chrome-extension",
"extension_version": "1.0.70",
"os_platform": "Windows",
"device_id": "<uuid>",
"oauth_token": "sk-ant-oat01-..." }
receive: { "type": "error",
"error": "OAuth token forbidden (403) —
missing scope or org access",
"reason": "upstream_403",
"upstream_status": 403,
"transient": false }
WS close
GET /api/oauth/profile → 200 OK
(immediately retry)
\
\\

Key observations:

  • All 25 WebSocket attempts received the identical 403 error
  • Server explicitly sets "transient": false — indicating retry

will not help

  • A new OAuth token is minted every cycle — token rotates each

retry, but every fresh token receives the same 403

  • All HTTP requests return 200 — there are no failed REST calls;

the failure is exclusively at the WebSocket layer

  • The OAuth profile endpoint reports the user is authenticated

successfully, yet the bridge rejects the same identity

Suspected Root Cause

Two overlapping issues:

  1. Server-side authorization bug: The OAuth token issued to the

user is missing the scope or org access required by
bridge.claudeusercontent.com. This happens immediately after
login — never works for this account. Possibly related to scope
issues in #29628 and #34176.

  1. Client-side retry-loop bug: The extension does not honor the

server's transient: false flag and retries indefinitely. There
appears to be no exponential backoff or retry cap. This turns a
single auth misconfiguration into a continuous flicker/logout
loop that destroys user state.

The client behavior is independently a bug — even when the underlying
auth issue is fixed, the extension should not retry non-transient
errors aggressively, and should not destroy user-visible state on
each retry.

Steps to Reproduce

  1. Install Claude in Chrome v1.0.70 (ID: fcoeoabgfenejglbffodgkkbkcdhcgfn)
  2. Log in with affected account [details available privately if needed]
  3. Open the side panel, start a conversation
  4. Within ~10–20 seconds: side panel flickers
  5. After several flicker cycles: forced redirect to login
  6. Conversation context is lost
  7. Re-login produces the same loop

Expected Behavior

  • WebSocket bridge accepts the OAuth token issued to a logged-in user

(server-side fix), OR clearly surfaces the actionable error to the
user (e.g., "Your account does not have access to Claude in Chrome —
contact your admin")

  • On transient: false errors, the client stops retrying and shows an

actionable error UI instead of looping

  • Conversation state is preserved across transient WebSocket reconnects

Actual Behavior

  • WebSocket bridge returns persistent 403 immediately on every connect
  • Client retries indefinitely, treating non-transient error as transient
  • Each retry cycle re-renders the side panel (visible flicker)
  • After enough failures, user is logged out and conversation is wiped

Environment

  • Extension version: 1.0.70
  • Extension ID: fcoeoabgfenejglbffodgkkbkcdhcgfn
  • OS: Windows (per WebSocket payload os_platform: "Windows")
  • Chrome version: [TODO — chrome://version]
  • Account type: [TODO — Pro / Team / Enterprise / Free]
  • Org membership: [TODO — relevant if "missing org access" applies]

Tangentially related observations (likely not root cause)

While investigating, the following were also noted but appear unrelated
to the flicker/logout loop:

  • CSP violations on options.html#options:8 for inline scripts

and a third-party Segment/Amplitude CDN load
(cdn.segment.com/.../amplitude-plugins/...). These are Manifest V3
compliance issues but the side panel and service worker continue
functioning despite them.

  • Service worker is healthy during the loop:

Installation: ACTIVATED, Running: RUNNING, Version ID: 76
(per chrome://serviceworker-internals). The service worker
console log is empty.

  • Build artifact name service-worker.ts-gaAAsstG.js retains

the .ts extension before the content hash — minor, but unusual
for a production build.

Suggested Triage

  1. Investigate why bridge service rejects OAuth tokens for this account

with missing scope or org access — coordinate with auth team

  1. Add client-side handling for transient: false errors: stop

retrying, show actionable error UI

  1. Add exponential backoff and retry cap to WebSocket reconnect logic

regardless of error type

  1. Decouple side panel UI state from WebSocket connection lifecycle so

transient reconnects do not visibly re-render or clear conversations

Attachments (please request privately — contain credentials)

  • HAR file with full WebSocket payloads (contains rotating OAuth tokens —

do not share publicly)

  • Service worker internals snapshot
  • Screenshots of CSP errors

What Should Happen?

The Claude in Chrome side panel should maintain a stable session
during normal use. Specifically:

  1. The WebSocket bridge at bridge.claudeusercontent.com should accept

the OAuth token issued to a successfully logged-in user. If the
token genuinely lacks required scope or org access, the user should
see a clear, actionable error message (e.g., "Your account does
not have access to Claude in Chrome — please contact your admin")
instead of being silently logged out.

  1. When the server returns an error with "transient": false, the

client should stop retrying and surface the error to the user,
not loop indefinitely.

  1. Conversation context in the side panel should persist across

transient WebSocket reconnects. The UI should not be destroyed
on every reconnect attempt.

  1. Users should not be forcibly redirected to the login screen

without explicit action (logout button, expired session after
long idle, etc.).

Error Messages/Logs

Steps to Reproduce

  1. Install Claude in Chrome v1.0.70 from the Chrome Web Store

(Extension ID: fcoeoabgfenejglbffodgkkbkcdhcgfn)

  1. Log in with an Anthropic account
  2. Open the side panel and start a conversation
  3. Open DevTools on the side panel → Network tab → enable "Preserve log"
  4. Wait 10-20 seconds during normal use

Observed loop (repeats every ~10-20 seconds):
a. POST https://platform.claude.com/v1/oauth/token → 200 OK
(fresh token issued)
b. WebSocket connect to wss://bridge.claudeusercontent.com/chrome/<id>
Sends: { "type": "connect", "extension_version": "1.0.70",
"oauth_token": "sk-ant-oat01-..." }
Receives: { "type": "error",
"error": "OAuth token forbidden (403) —
missing scope or org access",
"reason": "upstream_403",
"upstream_status": 403,
"transient": false }
c. WebSocket closes
d. GET /api/oauth/profile → 200 OK
e. Side panel flickers (visible re-render)
f. Loop restarts

After enough cycles: side panel forcibly redirects to login screen,
all conversation context is permanently lost. Re-login reproduces
the same loop.

In a 5-minute capture, this loop repeated 25 times with 116 total
network requests. Every WebSocket attempt received the identical
non-transient 403, but a NEW oauth token was minted each cycle
(token rotates every retry, all tokens get the same 403).

Additional context:

  • Service worker remains healthy throughout (status: ACTIVATED +

RUNNING, console log empty per chrome://serviceworker-internals)

  • All HTTP REST calls return 200; failure is exclusively at the

WebSocket layer

  • HAR file with full payloads available on request

(contains rotating OAuth tokens, cannot be shared publicly)

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

N/A — this is a Claude in Chrome extension bug, not Claude Code CLI. Claude in Chrome extension version: 1.0.70 Extension ID: fcoeoabgfenejglbffodgkkbkcdhcgfn

Platform

Other

Operating System

Windows

Terminal/Shell

Other

Additional Information

_No response_

View original on GitHub ↗

13 Comments

porjarlearnchaiyong-hash · 3 months ago

@anthropic-team This issue was auto-labeled invalid but I believe
this is incorrect. This is a Claude in Chrome browser extension bug,
which is actively triaged in this repository. Reference issues with
area:browser-extension label that were accepted here:

  • #46514 — Claude in Chrome service worker connection issue
  • #50157 — Claude in Chrome blocks navigation to claude.ai
  • #34176 — Claude in Chrome OAuth redirect failure
  • #29628 — Claude in Chrome OAuth scope error (related to this issue)

The bug I reported involves the Claude in Chrome extension v1.0.70
running an infinite OAuth retry loop against bridge.claudeusercontent.com
that returns persistent 403 with "transient": false. This causes
visible side panel flicker and forced logout, destroying conversation
context.

Please remove the invalid label and route to the browser-extension
team. Could a maintainer add the area:browser-extension label?

I have a HAR file with full reproducer (contains rotating OAuth tokens,
available privately on request). Happy to provide additional debugging
data.

porjarlearnchaiyong-hash · 3 months ago

Additional evidence — flicker also occurs on options.html

Update: I confirmed the flicker is not limited to the side panel.
The same flicker behavior occurs on:

chrome-extension://fcoeoabgfenejglbffodgkkbkcdhcgfn/options.html

This significantly broadens the impact and narrows the root cause:

  • The bug affects all UI pages of the extension that share the

auth/WebSocket state, not just sidepanel.html

  • This rules out side-panel-specific React state corruption as the

cause

  • It strengthens the case that the root cause is shared

auth/connection logic that runs across all extension pages

  • The earlier-reported CSP violations on options.html#options:8

may be more relevant than initially assessed — they originate
from the exact page that also flickers

This is a clear Claude in Chrome browser extension bug, not a
Claude Code CLI issue. Please reconsider the invalid label.

porjarlearnchaiyong-hash · 3 months ago

Hi Anthropic Support,

I'm a Claude Max subscriber experiencing a critical bug in the
Claude in Chrome extension that makes it unusable. I've already
filed a GitHub issue at [URL] but it was incorrectly auto-labeled
"invalid", so I'm escalating here.

Summary

The Claude in Chrome side panel and options page both flicker
continuously and force-redirect to login, wiping all conversation
context. Network analysis (HAR) shows an infinite OAuth retry loop:

  1. Extension obtains a fresh OAuth token (POST /v1/oauth/token → 200)
  2. Connects to wss://bridge.claudeusercontent.com/chrome/<id>
  3. Bridge returns:

{ "type": "error",
"error": "OAuth token forbidden (403) — missing scope or org access",
"reason": "upstream_403",
"upstream_status": 403,
"transient": false }

  1. WebSocket closes
  2. Loop restarts within 10–20 seconds

In a 5-minute capture, this happened 25 times.

Why this looks like a server-side issue

  • I am a Claude Max subscriber (active, auto-renews May 29, 2026)
  • Max plan should include Claude in Chrome access
  • /api/oauth/profile returns 200 — auth itself works
  • Only the bridge WebSocket rejects the token
  • Every fresh token gets the same 403 with the same reason
  • Server marks the error as non-transient

Account details

  • Subscription: Max plan ($88.47, auto-renews May 29, 2026)
  • Payment: active, last invoice paid Apr 29
  • Email: [your email]
  • Extension version: 1.0.70 (extension ID: fcoeoabgfenejglbffodgkkbkcdhcgfn)
  • OS: Windows
  • Device ID (from WebSocket payload): e5ba5905-6199-46f7-ba6d-d3af3a29e5f5

Impact

Claude in Chrome is completely unusable on my account. Every session
is destroyed within 1–2 minutes of starting.

What I need

  1. Investigation into why the OAuth bridge rejects tokens issued to

my account

  1. Confirmation whether this is account configuration (which support

could fix immediately) or a deeper extension/server bug

  1. If it's a known issue, an ETA for resolution

I have a HAR file with full reproducer that I can share privately
(it contains rotating OAuth tokens, so I'm not posting it publicly).
Please let me know how to securely share it with your engineering team.

Reference GitHub issue: [your GitHub issue URL]

Thanks,
[Your name]

porjarlearnchaiyong-hash · 3 months ago

Update — additional evidence + relabel request

Adding new findings since this was auto-labeled invalid:

1. Confirmed server-side via multi-device test

Reproduces identically on 2 different Windows machines with:

  • Fresh Chrome profiles
  • Fresh extension installations
  • Fresh OAuth tokens (rotates per retry)
  • All settings verified correct

This rules out: local cache, stale tokens, extension corruption,
profile state, cookies. The bug follows the account, not the
device — confirming server-side OAuth scope provisioning issue.

2. Affects all extension UI pages — not just side panel

  • chrome-extension://[id]/sidepanel.html flickers
  • chrome-extension://[id]/options.html flickers (verified by

attempting to view Claude in Chrome settings — page itself
flickers while open)

Rules out side-panel-specific React state corruption. Root cause
is shared auth/WebSocket logic.

3. Account context (filling in TODOs from original report)

  • Plan: Max (active, $88.47/mo, auto-renews May 29, 2026)
  • Account email: personal email (not business domain — rules

out the org-domain hypothesis from #34990)

  • Region: Bangkok, Thailand
  • Chrome version: 148.0.7778.97 (Official Build, 64-bit)

4. Settings verified correct

  • /api/oauth/profile returns 200 (auth itself works)
  • claude.ai → Settings → Claude in Chrome: "Allow extension"
  • No blocked sites configured
  • Service worker healthy (ACTIVATED + RUNNING, version stable,

console empty)

5. Standard troubleshooting does NOT resolve

Full cycle attempted: sign out → clear all cookies (claude.ai,
claudeusercontent.com, anthropic.com) → uninstall extension →
wait 5 min → fresh install → fresh login. Same 403 immediately.

6. Related issues — same bridge.claudeusercontent.com 403

This appears connected to a broader pattern of OAuth scope
issues with the bridge:

  • #55611 — Cowork bridge connection failure (same exact error

message, different flow — Pro plan)

  • #48806, #44541, #41034 — earlier Cowork bridge failures
  • #34785 — token refresh produces tokens missing required scopes
  • #34990 — Max account, business domain, missing

user:sessions:claude_code scope

The common thread: bridge.claudeusercontent.com rejecting
OAuth tokens with missing scope or org access despite valid
authentication. Possibly different surface symptoms of the same
underlying scope-provisioning bug.

Request for triage

Could a maintainer please:

  1. Remove invalid label — this IS a Claude in Chrome bug

filed in the established repo for browser extension issues
(precedent: #46514, #50157, #29628, #34176 all accepted with
area:browser-extension)

  1. Add labels: area:browser-extension, area:auth, bug,

platform:windows

  1. Link to #55611 if same root cause

Support escalation status

  • Filed support ticket via support.claude.com
  • AI agent (Fin) confirmed inability to access account state or

escalate to engineering

  • Conversation ID: 215474228853141

Available evidence (private)

  • HAR files from 2 devices (~5 min each, contain rotating OAuth

tokens — cannot post publicly)

  • Service worker internals snapshot
  • DevTools console output

Happy to share via secure channel.

wasinngansathil1212-debug · 3 months ago

same issues

porjarlearnchaiyong-hash · 3 months ago

@anthropics <https://github.com/anthropics> — encountering the same error
message ("OAuth token
forbidden (403) — missing scope or org access" with transient: false from
bridge.claudeusercontent.com) but in a different flow:

Standalone Chrome extension on Max plan, not Cowork. The
side panel and options page both flicker every ~15s and force-redirect
to login, destroying conversation context.

Token rotates each retry — every fresh token gets the same 403.
Reproduces on 2 different Windows machines with fresh installs.

Tracked separately at #57365
<https://github.com/anthropics/claude-code/issues/57365> (my original
report) — please link
if same root cause. Full HAR analysis available there.

Adding here so triagers can see this 403 affects more than just
Cowork bridge connection.

ในวันที่ เสาร์ 9 พ.ค. 2026 เวลา 10:15 wasinngansathil1212-debug <
@.***> เขียนว่า:

wasinngansathil1212-debug left a comment (anthropics/claude-code#57365) <https://github.com/anthropics/claude-code/issues/57365#issuecomment-4411249936> same issues — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/57365#issuecomment-4411249936>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/CDOZVW2WLBZSVUC76L7LHLT4Z2PENAVCNFSM6AAAAACYWLTKU2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DIMJRGI2DSOJTGY> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you authored the thread.Message ID: @.***>
Mada-463725 · 3 months ago

same same

porjarlearnchaiyong-hash · 3 months ago

Can you improve one of them?

Message ID: @.***>
porjarlearnchaiyong-hash · 3 months ago

Nobody solved my problem.

ในวันที่ ส. 9 พ.ค. 2026 13:34 Por Jarlearnchaiyong <
@.***> เขียนว่า:

Can you improve one of them? > Message ID: @.***> >
porjarlearnchaiyong-hash · 3 months ago

Update — VPN test reveals token rotation pattern

Adding new findings since this was auto-labeled invalid:

1. Confirmed server-side via multi-device test

Reproduces identically on 2 different Windows machines with:

  • Fresh Chrome profiles
  • Fresh extension installations
  • Fresh OAuth tokens (rotates per retry)
  • All settings verified correct

This rules out: local cache, stale tokens, extension corruption, profile state, cookies. The bug follows the account, not the device.

2. Affects all extension UI pages — not just side panel

  • chrome-extension://[id]/sidepanel.html flickers
  • chrome-extension://[id]/options.html flickers (verified)

Rules out side-panel-specific React state corruption.

3. NEW: VPN test reveals token rotation issue

Tested with Cloudflare WARP (exit region: Singapore SIN):

Before VPN (Bangkok routing):

  • 403 from bridge.claudeusercontent.com immediately
  • "OAuth token forbidden — missing scope or org access"
  • transient: false
  • Flicker every ~15s, force logout in 1-2 min
  • 25 retry cycles in 5 min

After VPN (Singapore routing):

  • ✅ Initial connection works — extension functions normally
  • ✅ Can send messages successfully for several minutes
  • ❌ After some usage: flicker resumes
  • ❌ New error appears: POST /v1/messages 401 (Unauthorized)
  • Pattern: works → flicker after token rotation

Critical insight: This pattern strongly matches #34785 ("Token refresh produces tokens with missing scopes"). The VPN doesn't fix the bug — it shifts WHEN it manifests:

  • Bangkok routing: bad token from request #1
  • Singapore routing: good initial token, but rotation produces bad tokens after some time

This points to a token rotation pipeline bug that issues tokens with inconsistent scopes.

4. Account context (rules out org-domain hypothesis)

  • Plan: Max (active, $88.47/mo, auto-renews May 29, 2026)
  • Email: personal email (NOT business domain — rules out #34990)
  • Region: Bangkok, Thailand
  • Chrome version: 148.0.7778.97 (Official Build, 64-bit)

5. DNS resolution verified normal

nslookup bridge.claudeusercontent.com → 160.79.104.10 ✅
nslookup api.anthropic.com → 160.79.104.10 ✅ (same IP, Anycast)

Both resolve to Anthropic's IP block (160.79.104.0/21). Anycast routing means same IP routes to different regional servers — explaining how VPN changes behavior.

6. Settings verified correct

  • /api/oauth/profile returns 200 (auth itself works)
  • claude.ai → Settings → Claude in Chrome: "Allow extension"
  • No blocked sites configured
  • Service worker healthy (ACTIVATED + RUNNING)
  • Service worker console log: empty

7. Standard troubleshooting does NOT resolve

Full cycle attempted: sign out → clear all cookies → uninstall extension → wait 5 min → fresh install → fresh login. Same 403.

8. Other users confirming same issue

Two other users have commented "same issues" / "same same" on this thread, indicating this is not isolated to my account.

9. Related issues — same bridge.claudeusercontent.com 403

  • #55611 — Cowork bridge connection failure (same exact error)
  • #34785 — token refresh produces tokens missing required scopes ⭐ same mechanism as my VPN observation
  • #34990, #28583 — Max account scope issues
  • #48806, #44541, #41034 — earlier Cowork bridge failures

Hypothesis (refined)

Based on VPN test results, the most likely root cause is a token rotation pipeline bug where scope assignment is inconsistent across token issuance:

  • Some issued tokens have full scope → work correctly
  • Some issued tokens are missing scope → 401/403 from auth-gated endpoints
  • Anycast routing affects which backend issues the token, hence region-dependent symptoms

Request for triage

Could a maintainer please:

  1. Remove invalid label — this IS a Claude in Chrome bug (precedent: #46514, #50157, #29628, #34176)
  2. Add labels: area:browser-extension, area:auth, bug, platform:windows
  3. Link to #55611, #34785 (likely related root cause)

Support escalation status

  • Filed support ticket via support.claude.com
  • AI agent (Fin) confirmed inability to access account state or escalate to engineering
  • Conversation ID: 215474228853141

Available evidence (private)

  • HAR files from 2 devices (~5 min each, contain rotating OAuth tokens)
  • HAR file from VPN test (Singapore exit)
  • Service worker internals snapshot
  • DevTools console output (before & after VPN)

Happy to share via secure channel.

porjarlearnchaiyong-hash · 3 months ago
porjarlearnchaiyong-hash · 3 months ago

Update — Cowork is also affected (cross-product impact)

Tested Cowork mode in Claude Desktop App on Windows. Result confirms this bug has cross-product impact, not just Chrome extension UI:

Test

Asked Cowork: Open google.com and search for "weather Bangkok"

Result

Cowork attempted to invoke Claude in Chrome tools (response showed "Used Claude in Chrome (3 actions), loaded tools") but received:

"The Claude in Chrome extension isn't currently connected, so I can't open Chrome and run the search for you directly. To get this working, please make sure Chrome is open and the Claude in Chrome extension is installed and signed in."

Note: at the time of this test, the Chrome extension WAS installed, signed in, and visible in chrome://extensions — but it was in the broken state described in this issue (flickering, force-logout loop). Cowork couldn't establish connection because the extension's bridge connection is broken.

Implications

This confirms:

  1. Cowork depends on bridge.claudeusercontent.com for browser tools (same dependency as Chrome extension itself)
  2. The bug breaks BOTH products for affected accounts:
  • ❌ Claude in Chrome standalone (flicker + force logout)
  • ❌ Cowork browser tools (cannot establish connection)
  1. Impact scope is broader than Chrome extension UI — this also breaks Cowork's value proposition for browser-automation tasks

Comparison with #55611

#55611 reports: "Chrome extension works standalone, but Cowork can't connect to it."

In my case: BOTH are broken — extension flickers/force-logs out AND Cowork cannot establish browser connection.

Same root cause (bridge.claudeusercontent.com 403 / OAuth scope), different manifestations depending on extension's connection state.

What still works on my account

  • ✅ Desktop App Chat (no browser tools)
  • ✅ Web search via tools
  • ✅ Cowork file/code tasks (no browser dependency)
  • ✅ claude.ai direct in browser

What's broken

  • ❌ Claude in Chrome extension (UI flicker, force logout)
  • ❌ Cowork browser tools (Chrome connector reports "not connected")
  • ❌ Any feature requiring bridge.claudeusercontent.com

This significantly broadens the impact scope of this bug. Marking as cross-product issue would help engineering triage.

github-actions[bot] · 2 months ago

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.