fix(msteams): isolate thread sessions, outbound targeting, and attachment resolution by atharva-getboon · Pull Request #59294 · openclaw/openclaw

atharva-getboon · 2026-04-01T23:42:46Z

Summary

Fixes #58615 — msteams channel threads share the same session key, causing cross-thread context bleed.

Thread session isolation: Each Teams channel thread gets its own session key via resolveThreadSessionKeys(), gated by session.threadBindings.enabled config
Thread-scoped history: historyKey is now thread-aware so buildPendingHistoryContextFromMap doesn't mix channel-level and thread-level history
Outbound thread targeting: buildActivity() sets activity.replyToId before any early returns so proactive sends (text + file attachments via SharePoint/OneDrive) land in the correct thread
User mention preservation: New stripMSTeamsBotMentionTag() strips only the bot's <at> tag — other user mentions are preserved as @Name in agent context. A separate commandText (all mentions stripped) is used for slash command detection to avoid regressions.
Key normalization: Consistent toLowerCase() across session key, history key, and conversation store key derivations
Thread file attachment fix: Graph API fallback now triggers for mixed attachment types (text/html + file.download.info without downloadUrl), fixing file attachments not being visible in thread replies. Narrowed to only file-like content types to avoid unnecessary Graph calls for Adaptive Cards.
Thread-aware debounce: Debounce key includes replyToId when thread bindings enabled, preventing cross-thread message merging

AI-Assisted PR 🤖

Marked as AI-assisted
Fully tested (487 msteams tests pass, type-check clean, lint clean, build clean)
Session logs available on request
I understand what the code does
Bot review conversations resolved with commit references

Test plan

🤖 Generated with Claude Code

…targeting

…ion/history/store

…attachments

greptile-apps · 2026-04-01T23:47:52Z

Greptile Summary

This PR fixes cross-thread context bleed in the MS Teams channel by introducing per-thread session keys, thread-scoped history, and outbound replyToId targeting. It also improves mention handling (preserving non-bot @mentions in agent context) and addresses file attachment visibility in thread replies via Graph API fallback. The changes are well-scoped and accompanied by solid unit and integration test coverage.

Key changes:

Thread session isolation (message-handler.ts): resolveThreadSessionKeys() derives a per-thread session key when session.threadBindings.enabled is set; session key, history key, and store key all use a consistently lowercased threadId.
Outbound thread targeting (messenger.ts, conversation-store.ts): buildActivity sets activity.replyToId from the stored conversationRef.replyToId so proactive sends land in the correct thread.
Bot-mention isolation (inbound.ts): stripMSTeamsBotMentionTag replaces stripMSTeamsMentionTags; non-bot mentions are preserved as @Name instead of being silently dropped.
Graph API fallback broadening (inbound-media.ts): Fallback now triggers when any attachments are present and direct download yields nothing — fixing thread reply file attachments but potentially causing unnecessary Graph calls for non-downloadable attachment types (see inline comment).
Known gap documented: Feedback invoke events still use the channel-level session key; tracked in a TODO for a follow-up fix.

Confidence Score: 3/5

Safe to merge with minor concerns; the Graph fallback broadening may add unnecessary API calls for non-media attachment types.
The thread isolation logic is well-implemented and consistent. The two flagged issues are: (1) the Graph API fallback now triggers for all attachment types (not just HTML/file-download), which could cause spurious Graph calls for Adaptive Card messages — this is a P1 correctness concern for throughput/cost in channels with card-heavy traffic; (2) </> are not escaped in the bot-name regex, which is a safe-but-minor defensive gap. The core feature changes (session keys, replyToId, mention handling) are solid and well-tested.
extensions/msteams/src/monitor-handler/inbound-media.ts — the broadened Graph fallback condition warrants a closer look before merging in environments with Adaptive Card usage.

Comments Outside Diff (1)

extensions/msteams/src/monitor-handler/inbound-media.ts, line 57-66 (link)

Graph fallback now triggers for all attachment types, including non-downloadable ones

The condition was narrowed from onlyHtmlAttachments (all attachments are text/html) to hasAttachments (any attachment exists). While this correctly fixes the thread reply scenario (mixed text/html + file.download.info without downloadUrl), it now triggers a Graph API call for any message where direct download returns nothing — including messages with Adaptive Cards (application/vnd.microsoft.card.adaptive), Hero Cards, or other metadata-only content types that by design never yield downloadable media.

For every such message, downloadMSTeamsAttachments legitimately returns [] (nothing to download), but now an unnecessary Graph API call is issued, adding latency and consuming Graph quota.

A more targeted fix would limit the fallback to attachment types that are expected to have downloadable content but may be missing their URL:

This preserves the existing text/html behavior, adds the new file.download.info-without-downloadUrl case, and avoids spurious Graph calls for card attachment types.

Prompt To Fix With AI

This is a comment left during a code review.
Path: extensions/msteams/src/monitor-handler/inbound-media.ts
Line: 57-66

Comment:
**Graph fallback now triggers for all attachment types, including non-downloadable ones**

The condition was narrowed from `onlyHtmlAttachments` (all attachments are `text/html`) to `hasAttachments` (any attachment exists). While this correctly fixes the thread reply scenario (mixed `text/html` + `file.download.info` without `downloadUrl`), it now triggers a Graph API call for *any* message where direct download returns nothing — including messages with Adaptive Cards (`application/vnd.microsoft.card.adaptive`), Hero Cards, or other metadata-only content types that by design never yield downloadable media.

For every such message, `downloadMSTeamsAttachments` legitimately returns `[]` (nothing to download), but now an unnecessary Graph API call is issued, adding latency and consuming Graph quota.

A more targeted fix would limit the fallback to attachment types that are *expected* to have downloadable content but may be missing their URL:



This preserves the existing `text/html` behavior, adds the new `file.download.info`-without-`downloadUrl` case, and avoids spurious Graph calls for card attachment types.

How can I resolve this? If you propose a fix, please make it concise.

Prompt To Fix All With AI

This is a comment left during a code review.
Path: extensions/msteams/src/monitor-handler/inbound-media.ts
Line: 57-66

Comment:
**Graph fallback now triggers for all attachment types, including non-downloadable ones**

The condition was narrowed from `onlyHtmlAttachments` (all attachments are `text/html`) to `hasAttachments` (any attachment exists). While this correctly fixes the thread reply scenario (mixed `text/html` + `file.download.info` without `downloadUrl`), it now triggers a Graph API call for *any* message where direct download returns nothing — including messages with Adaptive Cards (`application/vnd.microsoft.card.adaptive`), Hero Cards, or other metadata-only content types that by design never yield downloadable media.

For every such message, `downloadMSTeamsAttachments` legitimately returns `[]` (nothing to download), but now an unnecessary Graph API call is issued, adding latency and consuming Graph quota.

A more targeted fix would limit the fallback to attachment types that are *expected* to have downloadable content but may be missing their URL:

```suggestion
    const shouldFallbackToGraph =
      attachments.length > 0 &&
      attachments.some(
        (att) =>
          String(att.contentType ?? "").startsWith("text/html") ||
          String(att.contentType ?? "").includes("file.download.info"),
      );

    if (shouldFallbackToGraph) {
```

This preserves the existing `text/html` behavior, adds the new `file.download.info`-without-`downloadUrl` case, and avoids spurious Graph calls for card attachment types.

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: extensions/msteams/src/inbound.ts
Line: 122-123

Comment:
**Regex escaping omits `<` and `>` — may break if bot name contains those characters**

The escaping function covers regex metacharacters (`.*+?^${}()|[\]`) but does not escape `<` or `>`. While `<` is not a regex metacharacter, `>` appears in the surrounding pattern `<at[^>]*>…</at>`, so a bot name containing `>` would prematurely close the `[^>]*` alternation and potentially cause the regex to match/corrupt unintended content.

Example: if `botMentionName = "Bot >v2"`, the compiled regex becomes  
`<at[^>]*>Bot >v2</at>` where the `>` in `Bot >v2` terminates the `[^>]*` character class.

Bot display names containing `<`/`>` are unusual in Teams, but defensive escaping costs nothing:

```suggestion
  const escaped = botMentionName.replace(/[.*+?^${}()|[\]\\<>]/g, "\\$&");
```

(Note: `<` and `>` are not special in JS regex, so escaping them is harmless and produces the expected literal match.)

How can I resolve this? If you propose a fix, please make it concise.

_{Reviews (1): Last reviewed commit: "msteams: fix Graph API fallback not trig..." | Re-trigger Greptile}

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 9213f05201

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

…ape <> in bot name regex

…read-aware debounce key

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: eaee7238d8

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

…name

…name breaking /slash commands

chatgpt-codex-connector

💡 Codex Review

openclaw/extensions/msteams/src/monitor-handler/message-handler.ts

Line 722 in 35d331d

return !core.channel.text.hasControlCommand(entry.text, cfg);

Use mention-stripped text for command debounce checks

After this change, entry.text can start with preserved mentions (for example @Alice /status), so hasControlCommand(entry.text, cfg) returns false and the message is incorrectly debounced. That lets mention-prefixed slash commands be coalesced with subsequent messages in the debounce window, which can delay or alter command handling compared to the previous non-debounced path. The debounce gate should check entry.commandText (or another mention-stripped form) so command messages still bypass debounce reliably.

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

…tion-prefixed slash commands

atharva-getboon · 2026-04-02T18:59:04Z

@onutc @osolmaz Could you review this when you get a chance? This fixes thread session isolation, outbound reply targeting, file attachment visibility, and mention handling in the msteams plugin. All bot review conversations have been resolved with commit references.

…olation-58615 # Conflicts: # extensions/msteams/src/inbound.ts # extensions/msteams/src/monitor-handler/inbound-media.test.ts # extensions/msteams/src/monitor-handler/inbound-media.ts # extensions/msteams/src/monitor-handler/message-handler.ts

vicboon · 2026-04-09T00:34:53Z

@BradGroux @steipete @vincentkoc PTAL 🙏
This PR should be ready.

openclaw-barnacle · 2026-04-09T00:35:01Z

Please don’t spam-ping multiple maintainers at once. Be patient, or join our community Discord for help: https://discord.gg/clawd

hay7a4jhgqjw4 · 2026-04-14T20:07:08Z

I am linking a newly opened follow-up issue here because I think it may be related but not fully covered by #58615.

Related issue:

[Bug]: MSTeams malformed mixed thread session key from old-session reselection #66771 [Bug]: MSTeams malformed mixed thread session key from old-session reselection

Why I think this PR is relevant but may not be the whole story:

[Bug]: msteams channel threads share the same session key (cross-thread context bleed) #58615 is the simpler failure mode where multiple Teams channel threads collapse to the same base session key because thread qualification is missing.
In my newer investigation, I observed a malformed key of the form:
...:thread:OLD_THREAD_ID:thread:NEW_THREAD_ID
That suggests a different or later-stage failure mode: an old session path may be reselected first, and then a new thread id is appended afterward.

So if this PR fixes:

per-thread key derivation
outbound targeting
thread-scoped history

that is excellent and likely necessary.

But I would still recommend verifying one additional negative case before considering this whole class closed:

when a previous thread in the same Teams channel already has persisted session state, does a new thread ever produce a malformed doubly-threaded key like ...:thread:old:thread:new?

If the answer is no after this PR, then great, this PR may implicitly cover more than #58615. If not, #66771 may remain as a follow-up bug around old-session reselection / binding / target-session resolution.

grafoteka · 2026-04-22T10:30:57Z

Adding production confirmation for this PR.

Running OpenClaw v2026.4.21 in a multi-channel MS Teams deployment (11 channels, mix of DMs and threads). Without the thread session isolation this PR introduces, we observe two consistent symptoms:

Thread session key not qualified → cross-thread context bleed when multiple threads are active in the same channel
Outbound reply ignores replyToId → related to fix(msteams): preserve channel thread isolation during proactive fallback #59314, proactive fallback posts to channel top-level

The combined fix (per-thread session + replyToId in buildActivity) addresses both. PR #59314 covers the specific proactive-path sub-case; this PR is the broader correctness fix.

Happy to test against our deployment if that helps land this.

Thanks @atharva-getboon for the work.

clawsweeper · 2026-05-01T02:13:15Z

Codex review: needs changes before merge.

Summary
The PR changes the Microsoft Teams plugin to add thread-aware session/history/debounce routing, preserve non-bot mentions, improve outbound thread targeting, broaden file attachment fallback handling, and add related tests.

Reproducibility: yes. #58615 gives a concrete two-thread Teams reproduction, and current main still has a code-level reproduction for rapid same-sender messages because debounce and pending-history keys omit the Teams thread id.

Next step before merge
A focused automated replacement is plausible because the remaining repair is localized to the MS Teams plugin and changelog.

Security
Cleared: The PR touches channel plugin TypeScript/tests and formatting-only files, with no dependency, workflow, package metadata, secrets, or new third-party execution surface changes.

Review findings

[P2] Honor the effective thread binding policy — extensions/msteams/src/monitor-handler/message-handler.ts:391-396
[P3] Add the required changelog entry — extensions/msteams/src/monitor-handler/message-handler.ts:391

Review details

Best possible solution:

Rebase or replace this PR with a narrow MS Teams-only change on current main that preserves shipped threadId and proactive ;messageid= routing while adding thread-aware debounce/history keys, effective thread-binding policy handling, focused attachment/mention decisions, tests, and a changelog entry.

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

Yes. #58615 gives a concrete two-thread Teams reproduction, and current main still has a code-level reproduction for rapid same-sender messages because debounce and pending-history keys omit the Teams thread id.

Is this the best way to solve the issue?

No. The direction is useful, but the patch is stale and its thread-binding gate is not the narrowest maintainable fix because OpenClaw's effective policy supports channel/account overrides and default-enabled behavior.

Full review comments:

[P2] Honor the effective thread binding policy — extensions/msteams/src/monitor-handler/message-handler.ts:391-396
The new gate only checks cfg.session?.threadBindings?.enabled === true, but OpenClaw also supports channel/account threadBindings.enabled overrides and default-enabled behavior. A Teams install relying on those supported settings would still take the unthreaded session/history/debounce path, leaving the cross-thread bleed this PR is meant to fix.
Confidence: 0.86
[P3] Add the required changelog entry — extensions/msteams/src/monitor-handler/message-handler.ts:391
This is a user-facing Microsoft Teams fix, but the PR file list does not include CHANGELOG.md. Repo policy requires a single-line changelog entry for user-facing fix changes before merge.
Confidence: 0.94

Overall correctness: patch is incorrect
Overall confidence: 0.78

Acceptance criteria:

pnpm test extensions/msteams/src/monitor-handler/message-handler.thread-session.test.ts extensions/msteams/src/monitor-handler/inbound-media.test.ts extensions/msteams/src/messenger.test.ts extensions/msteams/src/inbound.test.ts
pnpm exec oxfmt --check --threads=1 extensions/msteams/src/monitor-handler/message-handler.ts extensions/msteams/src/monitor-handler/thread-session.ts extensions/msteams/src/monitor-handler/inbound-media.ts extensions/msteams/src/inbound.ts extensions/msteams/src/messenger.ts CHANGELOG.md
pnpm check:changed in Testbox before handoff if runtime code changes remain

What I checked:

PR intent and production context: The PR body says it fixes [Bug]: msteams channel threads share the same session key (cross-thread context bleed) #58615 by isolating Teams channel thread sessions, thread-scoping history, targeting outbound replies, preserving non-bot mentions, and fixing thread file attachments; a production comment reports cross-thread context bleed and proactive top-level replies on v2026.4.21. (41508e2a65fa)
Current main already has basic thread session derivation: Current main extracts a Teams channel thread root from conversation.id;messageid= or activity.replyToId and applies resolveMSTeamsRouteSessionKey after route resolution. (extensions/msteams/src/monitor-handler/message-handler.ts:243, 40f2bf395059)
Current main still has unthreaded pending history: Skipped-message history and pending history still use the normalized channel conversationId as historyKey, so skipped messages from separate Teams channel threads can still be mixed. (extensions/msteams/src/monitor-handler/message-handler.ts:536, 40f2bf395059)
Current main still has unthreaded debounce keys: The inbound debouncer key is msteams:<appId>:<conversationId>:<senderId> and omits thread identity, so rapid messages from the same sender in different channel threads can coalesce under the last thread context. (extensions/msteams/src/monitor-handler/message-handler.ts:917, 40f2bf395059)
Thread binding policy supports scoped overrides: The shared policy resolves thread binding state from channel/account scope and global session.threadBindings, with default-enabled behavior; the PR diff's direct global-only check does not match that contract. (src/channels/thread-bindings-policy.ts:127, 40f2bf395059)
Changelog entry is missing: The PR file list does not include CHANGELOG.md, and a local changelog search did not find this PR or contributor attribution. (CHANGELOG.md:1, 40f2bf395059)

Likely related people:

sudie-codes: Authored the current main commits for MS Teams channel thread session isolation, proactive thread routing, and later thread parent context injection. (role: introduced current Teams thread behavior; confidence: high; commits: 38aa1edf76da, 9edfefedf7bf, 01ea7e49212a; files: extensions/msteams/src/monitor-handler/message-handler.ts, extensions/msteams/src/monitor-handler/thread-session.ts, extensions/msteams/src/messenger.ts)
Peter Steinberger: Dominant recent contributor in the msteams handler/messenger area and author of the shared pending-history and plugin SDK channel helper refactors that this fix needs to preserve. (role: shared routing/history maintainer; confidence: medium; commits: 521ea4ae5bcb, c70837f07d1f, 40f2bf395059; files: extensions/msteams/src/monitor-handler/message-handler.ts, src/plugin-sdk/reply-history.ts, src/channels/thread-bindings-policy.ts)
Vincent Koc: Recently maintained the msteams handler tests and shared thread/binding helper surfaces adjacent to this PR's expected validation path. (role: recent msteams test/refactor maintainer; confidence: medium; commits: d00ab0604838, 8c88fb68b772, 74e7b8d47b18; files: extensions/msteams/src/monitor-handler/message-handler.ts, extensions/msteams/src/monitor-handler/message-handler.thread-session.test.ts, src/channels/thread-bindings-policy.ts)
BradGroux: Maintains the Microsoft issue tracker context, has recent MS Teams plugin fixes, and co-authored the current thread parent context work. (role: adjacent Microsoft/Teams maintainer; confidence: medium; commits: fce81fccd859, dd2faa376492, 01ea7e49212a; files: extensions/msteams/src/monitor-handler/message-handler.ts, extensions/msteams/src/monitor-handler/thread-parent-context.ts, extensions/msteams/src/conversation-store.ts)

Remaining risk / open question:

No live Teams run was performed in this read-only review, so Graph attachment fallback and connector thread delivery still need targeted and ideally manual validation.
The branch is stale against current main and includes incidental formatting churn across unrelated plugins, so a repair may need a narrow replacement branch rather than a direct update.
[Bug]: MSTeams malformed mixed thread session key from old-session reselection #66771 may represent a distinct old-session reselection path that should be tested if the session-key path is touched.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 40f2bf395059.

…re-suffixed bases (openclaw#66771) When the inbound message handler reuses a `route.sessionKey` that was already thread-qualified by a prior turn (e.g. cached resolve-route hit, or the cache-miss return at src/routing/resolve-route.ts:696 whose object reference is then mutated in-place by message-handler.ts:489), naively appending the current thread id compounds into `…:thread:OLD:thread:NEW` and routes the turn to a malformed lane that splits same-thread context across turns. Strip any trailing `:thread:<id>+` segments from the base before delegating to resolveThreadSessionKeys. Thread ids never contain ':' so the segment boundary is unambiguous; the '+' covers pathological doubly-suffixed bases already in caches/persisted sessions from prior runs. This is defense-in-depth at the helper level, complementary to the larger handler refactor in openclaw#59294 (still open since 2026-04-01). Even after that or a routing-cache fix lands, making the helper itself idempotent prevents any future caller hygiene regression from re-introducing the bug. Adds four regression tests under a new "idempotency against pre-suffixed bases" describe block in message-handler.thread-session.test.ts: - already-thread-suffixed base + new thread → single clean suffix - doubly-thread-suffixed (already-malformed) base → collapsed to one - same-thread re-application is a fixed point - stale thread suffix + top-level inbound → bare base Closes openclaw#66771.

atharva-getboon added 7 commits April 1, 2026 15:39

msteams: add stripMSTeamsBotMentionTag to preserve non-bot user mentions

a8e3740

msteams: add replyToId to StoredConversationReference

8c1a7fe

msteams: set activity.replyToId in buildActivity for outbound thread …

6e255bd

…targeting

msteams: wire up thread session isolation in message handler

b31bda9

msteams: add thread isolation integration tests

5cfdd19

msteams: normalize threadId for consistent key derivation across sess…

ba73e99

…ion/history/store

msteams: fix Graph API fallback not triggering for thread reply file …

9213f05

…attachments

openclaw-barnacle Bot added channel: msteams Channel integration: msteams size: M labels Apr 1, 2026

greptile-apps Bot reviewed Apr 1, 2026

View reviewed changes

Comment thread extensions/msteams/src/inbound.ts

chatgpt-codex-connector Bot reviewed Apr 1, 2026

View reviewed changes

Comment thread extensions/msteams/src/messenger.ts Outdated

Comment thread extensions/msteams/src/monitor-handler/message-handler.ts

atharva-getboon added 2 commits April 1, 2026 16:51

msteams: narrow Graph API fallback to file-like attachment types, esc…

a131964

…ape <> in bot name regex

msteams: move replyToId before early returns in buildActivity, add th…

eaee723

…read-aware debounce key

chatgpt-codex-connector Bot reviewed Apr 2, 2026

View reviewed changes

Comment thread extensions/msteams/src/inbound.ts

Comment thread extensions/msteams/src/monitor-handler.ts

msteams: use all-mentions-stripped text for command parsing to avoid @…

35d331d

…name breaking /slash commands

atharva-getboon force-pushed the fix/msteams-thread-isolation-58615 branch from bd5109a to 35d331d Compare April 2, 2026 18:16

chatgpt-codex-connector Bot reviewed Apr 2, 2026

View reviewed changes

msteams: use commandText for debounce command detection to handle men…

f5eab44

…tion-prefixed slash commands

BradGroux mentioned this pull request Apr 12, 2026

WORKING: All Microsoft Issues and PRs #49126

Closed

hay7a4jhgqjw4 mentioned this pull request Apr 14, 2026

[Bug]: MSTeams malformed mixed thread session key from old-session reselection #66771

Open

omarshahine removed the channel: bluebubbles Channel integration: bluebubbles label Apr 19, 2026

BingqingLyu mentioned this pull request Apr 28, 2026

fix(msteams): isolate thread sessions, outbound targeting, and attachment resolution BingqingLyu/openclaw#1819

Open

15 tasks

BradGroux mentioned this pull request Apr 29, 2026

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

Draft

clawsweeper Bot mentioned this pull request May 1, 2026

fix(msteams): preserve channel thread isolation during proactive fallback #59314

Open

4 tasks

harrisali0101 mentioned this pull request May 7, 2026

fix(msteams): make resolveMSTeamsRouteSessionKey idempotent against pre-suffixed bases (#66771) #78850

Open

6 tasks

Uh oh!

Conversation

atharva-getboon commented Apr 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

AI-Assisted PR 🤖

Test plan

Uh oh!

greptile-apps Bot commented Apr 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Greptile Summary

Confidence Score: 3/5

Comments Outside Diff (1)

Uh oh!

Uh oh!

chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

Uh oh!

Uh oh!

chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

Uh oh!

Uh oh!

chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

atharva-getboon commented Apr 2, 2026

Uh oh!

vicboon commented Apr 9, 2026

Uh oh!

openclaw-barnacle Bot commented Apr 9, 2026

Uh oh!

hay7a4jhgqjw4 commented Apr 14, 2026

Uh oh!

grafoteka commented Apr 22, 2026

Uh oh!

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

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

atharva-getboon commented Apr 1, 2026 •

edited

Loading

greptile-apps Bot commented Apr 1, 2026 •

edited

Loading

clawsweeper Bot commented May 1, 2026 •

edited

Loading