So using a chrome browser from my mac, I am no longer able to log into the alpaca trading dashboard, was working fine for weeks, now logs in, I see the dashboard for a second, and then logs out. I used claude to debug and here are the findings
That’s the smoking gun. Here’s the full sequence the userscript caught:
You log in → it goes to the dashboard (/dashboard/overview genuinely loads at 18:21:52) → the dashboard fires two authenticated API calls → both come back 401 {"code":401,"message":"unauthorized"} → and ~0.1s later it bounces you to /account/login. So the login itself succeeds and mints a token, but Alpaca’s backend rejects that token with 401 when the dashboard tries to use it.
That’s why nothing browser-side fixed it — the handshake works; the server is refusing the authorization. Let me pull the exact endpoint that’s 401’ing (stripping the query string so the tool will show it).
Used claude-in-chrome integration
Used claude-in-chrome integration
Now it’s precise. The failing call is:
GET app.alpaca.markets/internal/paper_accounts/**58946c69-3597-4f17-8c1f-ad9995da7a15**/portfolio/history → 401 unauthorized
This is a paper trading account. Your dashboard loads, tries to pull the portfolio history for that specific paper account, gets a 401, and the app treats that single 401 as a session failure and logs you out — hence the loop. It’s not your browser and not your credentials; it’s that one paper account’s data being rejected. Let me look at the rest of the requests in that dashboard load to see what succeeded (like the accounts list) so we can tell whether that paper account is stale/orphaned versus a broader server issue.
Used claude-in-chrome integration
Used claude-in-chrome integration
Got it — this fully explains it, and it’s not your browser, your credentials, or anything you can fix by clearing data. Here’s the proof, from that same dashboard load:
The login and token are completely healthy — Cognito and authx.alpaca.markets/v1/oauth2/token all returned 200. And your token is authorized for the paper account (58946c69…): on that same account, in the same split second, these all succeeded —
…/paper_accounts/58946c69…/positions→ 200…/paper_accounts/58946c69…/orders→ 200…/paper_accounts/58946c69…/trade_account/margin→ 200authx…/paper-accounts/58946c69…/client-credentials→ 200
Only one endpoint failed:
…/paper_accounts/58946c69…/portfolio/history→ 401 (and it retried once — you can even see Alpaca fire token-refresh calls to Cognito at 52.6–52.7s trying to recover — still 401).
So a single Alpaca endpoint, portfolio/history, is returning 401 while every sibling endpoint on the same account with the same token returns 200. That’s a server-side bug on Alpaca’s portfolio-history service — not an auth problem. The reason it logs you out is that Alpaca’s dashboard has an over-aggressive global handler: any 401 → “session expired” → refresh-and-retry → still 401 → dump you back to login. One flaky endpoint is nuking your whole session.
What this means:
- You can’t fix this from your side — it’s Alpaca’s. Worth checking status.alpaca.markets and reporting it to Alpaca support with this exact evidence (portfolio/history 401 while positions/orders/margin return 200 for the same paper account). That’s a precise, hard-to-argue bug report.
If you want into the dashboard in the meantime, I can extend the Tampermonkey script to intercept that one broken portfolio/history response and hand the app a harmless empty result instead of the 401 — that stops the logout trigger and lets the dashboard load (the portfolio-history chart would just be blank until Alpaca fixes their end). Want me to build that workaround? Otherwise, disable the debug script for now and I’ll note this so we can revisit.