IDR-msteams-aad-sender-identity: feat(msteams): add AAD sender identi… by rrajp · Pull Request #89796 · openclaw/openclaw

rrajp · 2026-06-03T10:51:45Z

Summary

What problem does this PR solve?
When using OpenClaw with Microsoft Teams, the agent has no visibility into the sender's organizational identity (department, job title, email). This makes persona-aware routing and responses impossible without external monkey-patching of the bundled msteams channel at container startup.

Why does this matter now?
Enterprise deployments using MS Teams need the agent to know who is asking — for example, routing engineering questions differently from HR queries, or addressing users by their proper name/title. Currently this requires runtime patching of the built JS bundle via Docker volume mounts, which is fragile and breaks on every release.

What is the intended outcome?
A first-class, opt-in channels.msteams.senderIdentity config option that fetches the sender's Azure AD profile from Microsoft Graph and prepends a trusted ## Sender Identity block to the agent body. Profiles are cached in-process with a configurable TTL.

What is intentionally out of scope?

Signed identity JWTs for downstream service authorization (organization-specific)
Adaptive Card table rendering improvements (separate concern, separate PR)
Plugin SDK shim for external msteams installs (packaging/deployment concern)

What does success look like?
Setting channels.msteams.senderIdentity.enabled: true causes every inbound Teams message to include a JSON block with the sender's AAD id, displayName, email, department, and jobTitle — with zero external patches needed.

What should reviewers focus on?

The integration point in message-handler.ts — enrichment runs after access resolution but before ctxPayload is built
The caching strategy in fetchAadUserProfile (module-level Map with TTL)
Whether the GraphUser type extension (adding department, jobTitle) affects any existing consumers

Linked context

Which issue does this close?
Closes #

Which issues, PRs, or discussions are related?
N/A — this addresses a gap discovered during enterprise deployment with MS Teams. No existing issue tracked this.

Was this requested by a maintainer or owner?
No — this is a contributor PR based on real production pain. I was applying runtime patches via Docker volumes (patch-aad-enrichment.js, entrypoint.sh) to achieve this, and wanted to contribute a proper integration instead.

Real behavior proof (required for external PRs)

Behavior or issue addressed: Agent receives no sender identity context from MS Teams messages; persona-aware routing requires external monkey-patching.
Real environment tested: Docker-based OpenClaw deployment with MS Teams channel (Azure Bot registration, single-tenant, v2026.5.28).
Exact steps or command run after this patch: Configured channels.msteams.senderIdentity.enabled: true in openclaw.json, sent a DM to the bot from a Teams user with AAD profile populated (department: Engineering, jobTitle: Staff Engineer).
Evidence after fix: : (redacted runtime log from live Docker deployment):

Before :

After :

2026-06-03T11:30:12.346Z [debug] aad sender identity enriched {"sender":"29:1a2b3c4d-5e6f-7890-abcd-ef1234567890"}
2026-06-03T11:31:12.480Z [debug] aad sender identity enriched {"sender":"29:1a2b3c4d-5e6f-7890-abcd-ef1234567890"}
2026-06-03T11:31:13.666Z [debug] aad sender identity enriched {"sender":"29:1a2b3c4d-5e6f-7890-abcd-ef1234567890"}
2026-06-03T11:32:12.093Z [debug] aad sender identity enrichment failed {"error":"Request failed with status 403"}

[entrypoint] Applied msteams Adaptive Card table patch
[aad-patch] AAD enrichment injected into src-B0B2KbzO.js

Observed result after fix: Agent correctly sees sender department/title and can use it for routing. Cached lookups skip Graph API calls (confirmed via debug log on second message).
What was not tested: Multi-tenant bot scenarios, GCC/DoD cloud environments, User.Read.All permission denial behavior (returns null gracefully per unit tests).
Proof limitations or environment constraints: Tested in a single-tenant enterprise Azure AD environment. Runtime log redacted to remove user names. This evidence is from the equivalent patch-based approach; the PR internalizes the same logic into the extension properly.
Before evidence: Without the config flag, agent body contains only the raw message text with no sender identity context — unchanged from current main behavior.

Tests and validation

Which commands did you run?

pnpm test extensions/msteams/src/sender-identity.test.ts extensions/msteams/src/graph-users.test.ts  # 10 pass
pnpm test extensions/msteams/src/monitor-handler  # 59 pass (all 6 test files)
pnpm test extensions/msteams  # 70/72 pass; 2 pre-existing failures in sdk.test.ts (missing semver dep)

What regression coverage was added or updated?

sender-identity.test.ts — 5 tests: block building (full profile, missing fields, no id), formatting output
graph-users.test.ts — 5 tests: profile fetch, caching, Graph errors, empty input, missing id

What failed before this fix, if known?
No failures — this is a new feature (additive).

If no test was added, why not?
Tests were added. Integration-level message-handler tests were not added because the enrichment is opt-in (disabled by default) and the existing 59 monitor-handler tests confirm no regression.

Risk checklist

Did user-visible behavior change? Yes — when senderIdentity.enabled is set, the agent sees additional context in the message body. Disabled by default; no change for existing users.

Did config, environment, or migration behavior change? Yes — new optional config key channels.msteams.senderIdentity added to the schema. Additive only; existing configs are unaffected.

Did security, auth, secrets, network, or tool execution behavior change? Yes — when enabled, the bot makes Microsoft Graph API calls using its existing app credentials to fetch user profiles. Requires User.Read.All application permission (documented in type JSDoc).

What is the highest-risk area?
The Graph API call in the message handler hot path. A slow or failing Graph response could delay message processing.

How is that risk mitigated?

Feature is opt-in (disabled by default)
Graph failures are caught and logged at debug level; message processing continues without enrichment
Profiles are cached for 1 hour (configurable) to minimize API calls
Uses the existing tokenProvider already available in the handler (no new auth flow)

Current review state

What is the next action?
Ready for maintainer review.

What is still waiting on author, maintainer, CI, or external proof?
CI results on this PR. Author available for feedback.

Which bot or reviewer comments were addressed?
N/A — initial submission.

clawsweeper · 2026-06-03T10:53:47Z

Codex review: needs real behavior proof before merge. Reviewed June 21, 2026, 8:19 AM ET / 12:19 UTC.

Summary
The PR adds an opt-in channels.msteams.senderIdentity Teams config that fetches Microsoft Graph user profile fields, passes them as untrusted structured context, updates docs/metadata, and adds unit tests.

PR surface: Source +164, Tests +177, Docs +34, Generated 0. Total +375 across 11 files.

Reproducibility: Do we have a high-confidence way to reproduce the issue? The feature request itself is not a bug, but the blocking cache defect is source-reproducible by calling fetchAadUserProfile twice with the same aadObjectId and no tenantId; the second call reuses the bare-key cache.

Review metrics: 2 noteworthy metrics.

Teams config surface: 1 object added, 2 options added. channels.msteams.senderIdentity.enabled and cacheTtlMs create a new operator-facing Teams config contract.
Inbound external lookup: 1 Graph user lookup added on cache misses. The PR adds a network dependency to the Teams inbound hot path whenever the opt-in feature is enabled.

Stored data model
Persistent data-model change detected: persistent cache schema: extensions/msteams/src/config-ui-hints.ts, persistent cache schema: extensions/msteams/src/graph-users.test.ts, persistent cache schema: extensions/msteams/src/graph-users.ts, unknown-data-model-change: src/config/bundled-channel-config-metadata.generated.ts, vector/embedding metadata: extensions/msteams/src/config-ui-hints.ts. Confirm migration or upgrade compatibility proof before merge.

Merge readiness
Overall: 🧂 unranked krab
Proof: 🦪 silver shellfish
Patch quality: 🧂 unranked krab
Result: blocked until stronger real behavior proof is added.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

[P1] Fix the sender profile cache so it never stores entries under an unscoped bare AAD object ID.
[P1] Add redacted screenshots, terminal output, copied live logs, or a recording from a deployment built from this PR branch; redact private endpoints, phone numbers, names, emails, and tokens.
Get explicit maintainer approval for the new Graph permission and directory identity context boundary.

Proof guidance:

[P1] Needs stronger real behavior proof before merge: Screenshots/logs show useful live Teams behavior, but the PR body says they came from an equivalent patch-based Docker deployment rather than this PR branch; branch-built proof is still needed with private details redacted. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.

Risk before merge

[P1] The profile cache can still use a bare AAD object ID when tenant context is unavailable, which can mix directory profile data across enabled multi-tenant runtimes until TTL expiry.
[P1] The screenshots and logs are useful operational context, but they do not prove this PR branch in a packaged Teams/AAD deployment.
[P1] The feature requires User.Read.All application permission and forwards directory profile fields into agent context, so maintainers need an explicit product/security decision even though the context is untrusted.
[P1] When enabled, inbound Teams processing waits for a Graph user lookup on cache misses; slow Graph responses or repeated failures can delay message handling.
[P1] The open Teams Graph tenant PR at Support separate Teams Graph tenant #87169 overlaps tenant/auth direction and should be considered before settling the final sender-identity token contract.

Maintainer options:

Fix cache scoping and proof before merge (recommended)
Require tenant/authority-scoped caching or no caching when tenant context is unavailable, then ask for redacted proof from a deployment built from this PR branch.
Accept the opt-in identity surface knowingly
Maintainers can explicitly accept the new config and Graph permission boundary if they want directory profile metadata available to Teams agents.
Pause for Graph tenant direction
If separate Teams Graph tenant selection should land first, pause this PR until the token/tenant contract from Support separate Teams Graph tenant #87169 is settled.

Next step before merge

[P1] Human review is needed because branch-specific Teams/AAD proof and maintainer approval for the directory-profile/security boundary are still required; the cache fix alone is not enough to make this automergeable.

Security
Needs attention: The diff introduces a new Graph-backed directory identity path, and the bare-key cache fallback plus broad profile permission need maintainer security review before merge.

Review findings

[P1] Avoid caching profiles without a tenant-scoped key — extensions/msteams/src/graph-users.ts:31

Review details

Best possible solution:

Keep the untrusted-context design, but require tenant-safe caching, branch-specific Teams/AAD proof, and explicit maintainer approval for the new Graph-backed identity/config surface before merge.

Do we have a high-confidence way to reproduce the issue?

Do we have a high-confidence way to reproduce the issue? The feature request itself is not a bug, but the blocking cache defect is source-reproducible by calling fetchAadUserProfile twice with the same aadObjectId and no tenantId; the second call reuses the bare-key cache.

Is this the best way to solve the issue?

Is this the best way to solve the issue? Not yet: the untrusted structured context boundary is the right direction, but the best fix needs tenant-safe caching, branch-specific live proof, and maintainer approval for the directory-profile boundary.

Full review comments:

[P1] Avoid caching profiles without a tenant-scoped key — extensions/msteams/src/graph-users.ts:31
This still falls back to caching under the bare aadObjectId whenever tenantId is absent. Current Teams ingress treats tenant data as fallback-shaped, so an enabled multi-tenant process can reuse a directory profile across tenants until the TTL expires; skip caching without tenant/authority context or derive a scoped key from the same tenant fallback used by the handler.
Confidence: 0.83

Overall correctness: patch is incorrect
Overall confidence: 0.86

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against 12c34fc3a951.

Label changes

Label justifications:

P2: This is a normal-priority opt-in Teams feature/config PR with limited default blast radius but meaningful operator and security review requirements.
merge-risk: 🚨 compatibility: The PR adds an operator-facing channels.msteams.senderIdentity config surface that deployments may depend on after release.
merge-risk: 🚨 security-boundary: The PR fetches Microsoft Graph directory profile fields with application permission and forwards them into agent context when enabled.
merge-risk: 🚨 availability: The PR adds a Graph lookup before inbound Teams dispatch on cache misses, so Graph latency or failures can delay enabled message handling.
rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🦪 silver shellfish and patch quality is 🧂 unranked krab.
status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs stronger real behavior proof before merge: Screenshots/logs show useful live Teams behavior, but the PR body says they came from an equivalent patch-based Docker deployment rather than this PR branch; branch-built proof is still needed with private details redacted. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.
proof: 📸 screenshot: Contributor real behavior proof includes screenshot evidence. Screenshots/logs show useful live Teams behavior, but the PR body says they came from an equivalent patch-based Docker deployment rather than this PR branch; branch-built proof is still needed with private details redacted.

Evidence reviewed

PR surface:

Source +164, Tests +177, Docs +34, Generated 0. Total +375 across 11 files.

View PR surface stats

Area	Files	Added	Removed	Net
Source	7	165	1	+164
Tests	2	177	0	+177
Docs	1	34	0	+34
Config	0	0	0	0
Generated	1	9	9	0
Other	0	0	0	0
Total	11	385	10	+375

Security concerns:

[medium] Unscoped profile cache can cross tenant boundaries — extensions/msteams/src/graph-users.ts:31
When tenant ID is unavailable, the new in-process cache stores profile data under only aadObjectId, which can mix directory identity data in a multi-tenant process until the TTL expires.
Confidence: 0.83
[medium] Directory profile fields enter agent context — src/config/types.msteams.ts:214
The new opt-in feature requires User.Read.All application permission and forwards display name, email, department, and job title to the agent, so maintainers should explicitly approve this privacy and security boundary.
Confidence: 0.76

What I checked:

Repository policy applied: Root AGENTS.md plus scoped extensions/AGENTS.md and docs/AGENTS.md were read fully; their external API, config-surface, plugin-boundary, and docs-review rules directly apply to this PR. (AGENTS.md:1, 12c34fc3a951)
Current main lacks senderIdentity: Search of current main found no senderIdentity config or sender identity enrichment path; the current Teams inbound handler builds agent text from thread context and raw body only. (extensions/msteams/src/monitor-handler/message-handler.ts:760, 12c34fc3a951)
PR head routes identity as untrusted context: The PR head builds a Microsoft Teams sender identity untrusted structured context entry and passes it through extra.UntrustedStructuredContext, which current core context code preserves and renders as untrusted metadata. (extensions/msteams/src/monitor-handler/message-handler.ts:865, cd6c79af7e55)
Cache fallback remains unscoped: The PR head uses ${tenantId}:${aadObjectId} only when params.tenantId is present, but otherwise stores and reads under the bare AAD object ID. (extensions/msteams/src/graph-users.ts:31, cd6c79af7e55)
Current Teams code treats tenant context as fallback-shaped: Current main already handles tenant IDs as activity.channelData?.tenant?.id ?? conversation?.tenantId, so the PR should not cache profile data under an unscoped key when the same inbound activity can lack one tenant source. (extensions/msteams/src/monitor-handler/message-handler.ts:156, 12c34fc3a951)
Microsoft Graph user contract checked: Microsoft Learn documents GET /users/{id | userPrincipalName}, application User.Read.All as the least-privileged application permission for get-user, $select for non-default user properties, and the requested department, jobTitle, mail, userPrincipalName, and id user fields. (learn.microsoft.com)

Likely related people:

vincentkoc: Recent current-main Teams Graph/security work includes streaming Graph success responses and guarded Graph fetch handling in the same Graph helper area. (role: recent area contributor; confidence: medium; commits: 4799fe7df6c4, d0034e2f9912, c98459d9dafa; files: extensions/msteams/src/graph.ts, extensions/msteams/src/graph-users.ts)
steipete: Recent commits centralize inbound supplemental context and config docs/metadata surfaces that this PR extends with UntrustedStructuredContext and new Teams config keys. (role: recent inbound/config refactor owner; confidence: medium; commits: 1507a9701b83, 6989d6283a5b, 35e16051479f; files: src/channels/inbound-event/context.ts, src/config/types.msteams.ts, docs/channels/msteams.md)
sudie-codes: History shows substantial Teams Graph actions, delegated auth, pagination, and message-action work adjacent to the Graph profile lookup path. (role: Teams Graph feature contributor; confidence: high; commits: 355794c24a39, f71ee71787c7, 0f192710924f; files: extensions/msteams/src/graph.ts, extensions/msteams/src/graph-users.ts, src/config/types.msteams.ts)
heyitsaamir: Recent Teams SDK rebase work modified the same Teams Graph and inbound handler surfaces that this PR builds on. (role: recent Teams SDK/runtime contributor; confidence: medium; commits: 04c29825356f; files: extensions/msteams/src/graph.ts, extensions/msteams/src/monitor-handler/message-handler.ts, src/config/types.msteams.ts)
HDYA: Federated credential support changed Teams auth/token/config surfaces adjacent to the new Graph-backed sender identity feature. (role: Teams auth feature introducer; confidence: medium; commits: 26f633b604fd; files: extensions/msteams/src/sdk.ts, extensions/msteams/src/token.ts, src/config/types.msteams.ts)

What the crustacean ranks mean

🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

How this review workflow works

ClawSweeper keeps one durable marker-backed review comment per issue or PR.
Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
Maintainers can also comment @clawsweeper review to request a fresh review only.
Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

byungskers · 2026-06-03T11:08:28Z

Interesting feature, and I like that it’s opt-in.

One thing I’d want reviewed before merge: the in-process cache is keyed only by aadObjectId. For single-tenant deployments that’s probably fine, but if this extension can be used against multiple tenants/registrations in one process, I don’t think object IDs are guaranteed to be collision-safe across tenants. In that case we could end up reusing a cached profile from the wrong directory. Keying by something tenant-scoped (or including the authority/tenant context in the cache key) would make this a lot safer.

rrajp · 2026-06-03T11:13:06Z

@clawsweeper
CI note: The check-additional-extension-bundled / lint:extensions:bundled failure is a pre-existing extensions/copilot/ lint error that also fails on main. This PR's changed files (extensions/msteams/src/*) pass oxlint with zero errors — the 3 curly-brace issues were fixed in the follow-up commit.

rrajp · 2026-06-03T11:18:31Z

@byungskers Good catch !
AAD object IDs are GUIDs so collisions are extremely unlikely in practice, but it's a legitimate concern for multi-tenant bots. I have fixed it in 3c86a16. The cache key is now {tenantId}:{aadObjectId} when a tenant ID is available (from activity.channelData.tenant.id), so multi-tenant bots get isolated cache entries. Added a test that verifies the same object ID with different tenant IDs produces separate Graph calls and separate cached results.

…ty enrichment Add opt-in sender identity enrichment for the MS Teams channel that fetches the sender's Azure AD profile (displayName, email, department, jobTitle) from Microsoft Graph and prepends a trusted identity block to the agent body for persona-aware routing and responses. Enable via channels.msteams.senderIdentity.enabled in openclaw.json. Requires User.Read.All application permission on the bot's Azure AD app. Co-authored-by: Cursor <[email protected]>

…ine if statements Satisfy oxlint curly rule for graph-users.ts and sender-identity.ts. Co-authored-by: Cursor <[email protected]>

…y by tenantId Include the Azure AD tenant ID in the profile cache key so multi-tenant bots cannot leak cached profiles across directories. Co-authored-by: Cursor <[email protected]>

…ndings for sender identity - [P1] Move identity data from trusted prompt text to UntrustedStructuredContext, matching Discord/WhatsApp patterns for untrusted metadata - [P2] Remove PII (displayName, department) from debug log; log only senderId - [P2] Add config-ui-hints for senderIdentity, senderIdentity.enabled, senderIdentity.cacheTtlMs with permissions and privacy docs - Update types.msteams.ts JSDoc to reflect untrusted metadata model Co-authored-by: Cursor <[email protected]>

…adata and document senderIdentity - Regenerate bundled-channel-config-metadata.generated.ts to include senderIdentity schema and UI hints - Add Sender identity enrichment section to Teams docs with config, permissions (User.Read.All), privacy notes, and cloud limitation - Cross-reference sender identity from Graph capabilities section Co-authored-by: Cursor <[email protected]>

steipete · 2026-07-09T15:08:01Z

Thanks @rrajp. Closing this stale implementation under the stricter correctness/proof bar. The tenantless cache key can mix AAD directory profiles across tenants; the attached proof comes from an equivalent patch rather than this branch; and the branch adds User.Read.All plus synchronous Graph lookup to the inbound hot path. #87169 preserves the adjacent Teams Graph tenant direction for a focused replacement.

openclaw-barnacle Bot added channel: msteams Channel integration: msteams size: M triage: needs-real-behavior-proof Candidate: external PR needs after-fix proof from a real setup. labels Jun 3, 2026

openclaw-barnacle Bot added proof: supplied External PR includes structured after-fix real behavior proof. and removed triage: needs-real-behavior-proof Candidate: external PR needs after-fix proof from a real setup. labels Jun 3, 2026

BradGroux mentioned this pull request Jun 3, 2026

WORKING: All Microsoft Issues and PRs (refresh) #74163

Draft

openclaw-barnacle Bot added the docs Improvements or additions to documentation label Jun 5, 2026

rrajp and others added 5 commits June 5, 2026 20:22

IDR-msteams-aad-sender-identity: fix(msteams): add braces to single-l…

4dbe0e8

…ine if statements Satisfy oxlint curly rule for graph-users.ts and sender-identity.ts. Co-authored-by: Cursor <[email protected]>

IDR-msteams-aad-sender-identity: fix(msteams): scope profile cache ke…

cdd076b

…y by tenantId Include the Azure AD tenant ID in the profile cache key so multi-tenant bots cannot leak cached profiles across directories. Co-authored-by: Cursor <[email protected]>

rrajp force-pushed the IDR-msteams-aad-sender-identity branch from c91ffa5 to cd6c79a Compare June 5, 2026 14:53

clawsweeper Bot added the proof: 📸 screenshot Contributor real behavior proof includes screenshot evidence. label Jun 15, 2026

clawsweeper Bot mentioned this pull request Jun 21, 2026

Support separate Teams Graph tenant #87169

Closed

steipete closed this Jul 9, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

IDR-msteams-aad-sender-identity: feat(msteams): add AAD sender identi…#89796

IDR-msteams-aad-sender-identity: feat(msteams): add AAD sender identi…#89796
rrajp wants to merge 5 commits into
openclaw:mainfrom
rrajp:IDR-msteams-aad-sender-identity

rrajp commented Jun 3, 2026 •

edited

Loading

Uh oh!

clawsweeper Bot commented Jun 3, 2026 •

edited

Loading

Uh oh!

byungskers commented Jun 3, 2026

Uh oh!

rrajp commented Jun 3, 2026

Uh oh!

rrajp commented Jun 3, 2026

Uh oh!

steipete commented Jul 9, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Uh oh!

Conversation

rrajp commented Jun 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Linked context

Real behavior proof (required for external PRs)

Tests and validation

Risk checklist

Current review state

Uh oh!

clawsweeper Bot commented Jun 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

byungskers commented Jun 3, 2026

Uh oh!

rrajp commented Jun 3, 2026

Uh oh!

rrajp commented Jun 3, 2026

Uh oh!

steipete commented Jul 9, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

rrajp commented Jun 3, 2026 •

edited

Loading

clawsweeper Bot commented Jun 3, 2026 •

edited

Loading