LoopMe: Three blocking issues — API access entitlement, OAuth org routing, probe auth 401

[geneticallymodifiedfoodforthought]

Overview

LoopMe (org org_01KEC0X42PGV55T5N0GTQDAC6X, contact: mykola.danyliuk@loopme.com) has three blocking issues. Their agent passed all 6 tracks on 3.1 on 2026-07-03 and has been degraded since 2026-07-04. Mykola has done exceptional code-level analysis across multiple escalations — the blockers are well-understood, they just need Brian's authority or DB access to action.

---

Blocker 1: Commercial decision — does Founding Member entitle API-tier access?

Escalations: #464, #465, #468

is_api_access_tier is a derived boolean: membership_tier ∈ API_ACCESS_TIERS AND subscription_status ∈ {active, past_due, trialing}. API_ACCESS_TIERS = {individual_professional, company_standard, company_icl, company_leader}. Founding Member is not in that set.

Question for Brian: Does Founding Member entitle API-tier read access under their bespoke terms?

If yes, two implementation paths (neither is side-effect-free):

1. UPDATE organizations SET membership_tier = 'company_icl' WHERE id = 'org_01KEC0X42PGV55T5N0GTQDAC6X' — one-field change but re-labels Founding Member as a paid tier, may affect billing/badge logic
2. Code change: add Founding Member tier value to API_ACCESS_TIERS

Precedent check needed: What membership_tier is set on other comparable founding-era orgs (e.g. Scope3, Adzymic)? Do their org keys resolve is_api_access_tier: true?

Note: #463 was prematurely resolved — "engineering to flip the flag" was written before #464/#465 established there is no flag.

---

Blocker 2: DB band-aid — OAuth credential under wrong WorkOS org

Escalation: #474

resolveOwnerAuth JOINs on mp.workos_organization_id = ac.organization_id. The OAuth credential for https://platform.loopme.ai/mcp/seller was stored under the wrong org — the JOIN fails.

Immediate fix (unblocks heartbeat while code fix deploys):

UPDATE agent_credentials
SET organization_id = 'org_01KEC0X42PGV55T5N0GTQDAC6X'
WHERE agent_url = 'https://platform.loopme.ai/mcp/seller';

Code fix also needed: OAuth callback is routing credentials to wrong org even when initiated via ensureAgentContextId(ownerOrg). The dashboard Authorize button uses getAuthInfoByOrgAndUrl instead of ensureAgentContextId(ownerOrg) — separate bug.

Also: offline_access fix (#5823) merged but token issued before merge didn't benefit — credential expired ~24h post-auth with no refresh.

---

Blocker 3: Periodic compliance probe still 401ing after #5823

Escalation: #469

auth-status shows has_valid_oauth: true but discovery/health/compliance probes return 401 oauth_required ~1 min after token storage. diagnose_agent_auth returns "No likely failures."

• MCP Inspector completes full OAuth flow and calls tools/list successfully
• Token decodes to aud: ["https://platform.loopme.ai"], iss: https://login.loopme.com/ — correct shape
• Issue is isolated to resolveProbeAuth → findOrgWithSavedAuth path, which [codex] Fix durable OAuth probe auth and feed schema #5823 didn't touch
• Agent is healthy; problem is AAO-side probe credential injection

---

Summary of actions needed

#	Action	Owner
1	Commercial decision: Founding Member → API access?	Brian
2	DB: update ac.organization_id for LoopMe agent	Brian / eng
3	Code: fix OAuth callback org routing	Eng
4	Code: fix resolveProbeAuth credential injection	Eng

Related escalations

#464, #465, #468, #469, #474

[bokelley]

Triage

Classification: Bug (confirmed: wrong-org credential storage + downstream probe 401) + policy question (API entitlement)
Bucket(s): security-sensitive, admin/ops tools
Status: ready-for-human
Milestone: P0 Bugs

What the experts said:

• security-reviewer: No cross-tenant credential leak — getAuthInfoByOrgAndUrl is always scoped to (organization_id, agent_url), so the security model is intact. Critical finding: the raw UPDATE agent_credentials SET organization_id = … in the issue body would silently corrupt all stored ciphertexts — organization_id is the AES key-derivation salt; the fix must go through the application layer (saveOAuthTokens/saveAuthToken) after correcting the org context. Blocker 3 (findOrgWithSavedAuth → probe 401) is most likely a downstream symptom of Blocker 2's wrong-org data, not an independent code defect — diagnose after the data layer is corrected.
• internal-tools-strategist: The OAuth callback bug (getAuthInfoByOrgAndUrl instead of ensureAgentContextId) and the resolveProbeAuth lookup failure are causally linked but distinct; engineering can PR both independently of the entitlement decision. The DB correction needs application-layer execution, not raw SQL, and should be staged (SELECT → verify → transaction → commit) so it can fire within minutes of a go-ahead.

My take: Two parallel tracks: (1) Brian's commercial call on Founding Member API entitlement, needed before any is_api_access_tier change ships; and (2) a data-integrity bug where LoopMe's OAuth credential was written under the wrong org ID, blocking the heartbeat JOIN — the fix requires application-layer re-key, not the raw SQL in the issue body, and once corrected, Blocker 3 should be re-evaluated before treating it as a separate defect.

⚠️ Do not run the SQL UPDATE in the issue body as written. organization_id is the AES key-derivation salt for stored credentials; updating it without re-encrypting will silently corrupt the ciphertexts. Use saveOAuthTokens/saveAuthToken after correcting the org context.

---

@bokelley — two decisions needed before engineering can complete the unblock:

Decision 1 — Does Founding Member entitle is_api_access_tier?

API_ACCESS_TIERS currently = {individual_professional, company_standard, company_icl, company_leader}. Founding Member is absent.

Option A — Re-classify LoopMe to company_icl in DB (one-org fix):

# organizations row for org_01KEC0X42PGV55T5N0GTQDAC6X
- membership_tier: 'founding_member'
+ membership_tier: 'company_icl'

Unblocks immediately; semantically mislabels their tier and may touch billing/badge logic downstream.

Option B — Add founding_member to API_ACCESS_TIERS in code (applies to all Founding Members):

// API_ACCESS_TIERS constant
- ['individual_professional', 'company_standard', 'company_icl', 'company_leader']
+ ['individual_professional', 'company_standard', 'company_icl', 'company_leader', 'founding_member']

Semantically correct; confirm entitlement is universal, not a per-org accommodation. Precedent check on Scope3 / Adzymic org keys would help verify intent.

Decision 2 — Who runs the LoopMe credential re-key?

Engineering can stage the application-layer correction to agent_contexts for org_01KEC0X42PGV55T5N0GTQDAC6X; someone with prod DB access needs to confirm current state and execute (or trigger via admin tooling). Once the org is corrected and LoopMe re-authorizes via OAuth, Blocker 3 should be re-run before treating resolveProbeAuth as a separate code fix.

Engineering-only work (no decision needed): the OAuth callback routing fix (getAuthInfoByOrgAndUrl → ensureAgentContextId) and an org-existence guard at ensureAgentContextId/create time can be PRed now.

---

Triaged by Claude Code. Session: https://claude.ai/code/${CLAUDE_CODE_REMOTE_SESSION_ID}

---

Generated by Claude Code