feat: add channel mention notifications by jjjhenriksen · Pull Request #116 · openclaw/clickclack

jjjhenriksen · 2026-07-24T06:06:07Z

Summary

add one server-backed per-channel notification preference: all, mentions, or muted;
attach resolved mention user IDs to durable message and thread-reply events while keeping reply author/body content out of replayable metadata;
hydrate authorized thread messages only when alert text is needed;
enforce the same preference for Pushover and browser/desktop realtime alerts;
keep mention parsing out of Markdown links and supported URL-like tokens;
limit composer suggestions to users with resolvable handles;
refresh the feature onto the topic-enabled conversation model and regenerate SQL/web assets.

Real behavior proof

The focused Playwright scenario runs against the real ClickClack Go server and embedded production web app. It:

gives the signed-in user a mentionable profile handle;
creates an active channel and a background channel;
sets the background channel to muted, posts as a second real user, and observes zero browser notifications;
changes the setting through ClickClack to mentions, reloads, and verifies the persisted UI state;
posts an ordinary background message and observes zero browser notifications;
posts a mention and verifies the durable event contains the current user in mentioned_user_ids and exactly one browser notification appears;
changes the channel remotely from mentions to muted and then all, proving the already-running client suppresses and resumes alerts without a reload or channel selection;
posts a mentioned thread reply while all is active, verifies the durable event omits author_id and body, and observes the real reply text after authorized message hydration;
clicks the original notification and verifies navigation to the originating channel.

Exact-head command and result for d44b42e9e60cef731aff3073d35eb823265ae592:

pnpm exec playwright test tests/e2e/chat.spec.ts --grep "channel preferences filter browser notifications outside the active conversation" --reporter=line
1 passed (11.3s)

The captured browser proof shows the live channel header in the muted state:

The screenshot above is attached directly to this PR description; the proof image is not part of the feature branch.

Validation

pnpm check
passed

go test ./apps/api/internal/store/... ./apps/api/internal/httpapi/...
passed

pnpm generate:sqlc
passed

Exact-head GitHub verification:

The final design uses the channel preference as the single notification policy for alert delivery and later mention attention; local storage is only a last-known fallback when the server is temporarily unavailable. Durable events carry routing and resolved mention metadata, never thread-reply content.

jjjhenriksen · 2026-07-24T06:06:52Z

@clawsweeper re-review

clawsweeper · 2026-07-24T06:06:55Z

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: when the review finishes, ClawSweeper will create the durable review comment if needed or update the existing comment in place.

Re-review progress:

State: Review in progress
Detail: The exact-review queue leased this run; Codex is reviewing the item.
Run: https://github.com/openclaw/clawsweeper/actions/runs/30189704583
Updated: 2026-07-26T05:38:54.602Z

clawsweeper · 2026-07-26T03:44:11Z

Codex review: found issues before merge. Reviewed August 2, 2026, 5:34 PM ET / 21:34 UTC.

ClawSweeper review

What this changes

Adds per-channel all, mentions-only, and muted notification preferences across storage, HTTP and SDK APIs, Pushover, browser/desktop alerts, and the web UI.

Merge readiness

⚠️ Needs maintainer review before merge - 7 items remain

Keep open: current main still has only global message notifications, while this PR adds a distinct per-channel notification capability. Exact-head real-server proof is sufficient, but the branch still needs its release-owned changelog edit removed, its stale PR description corrected, and a maintainer decision on the new persistent preference contract.

Priority: P2
Reviewed head: d44b42e9e60cef731aff3073d35eb823265ae592
Owner decision: Required. See Decision needed.

Review scores

Measure	Result	What it means
Overall readiness	🦐 gold shrimp (3/6)	The feature has strong exact-head runtime proof, but a release-owned file edit, stale PR description, broad cross-cutting surface, and unconfirmed product direction keep it below merge-ready quality.
Proof confidence	🦞 diamond lobster (5/6)	Sufficient (terminal): An August 2 exact-head comment reports a passing focused real Go-server and embedded-web Playwright scenario covering persisted and live preference changes, message and reply alerts, and click-through navigation.
Patch quality	🦐 gold shrimp (3/6)	1 actionable review finding remain.

Verification

Check	Result	Evidence
Real behavior	Verified	Sufficient (terminal): An August 2 exact-head comment reports a passing focused real Go-server and embedded-web Playwright scenario covering persisted and live preference changes, message and reply alerts, and click-through navigation.
Evidence reviewed	6 items	Current main lacks the requested preference layer: Current Pushover delivery selects recipients solely from the message, and the web alert handler accepts only message.created; current main has no channel notification settings endpoint or preference type. Existing notification-path provenance: Blame attributes the current server-side notification dispatch path to Shakker's `55da179` commit, making that path the appropriate ownership route for the delivery change. Exact-head behavior proof: The August 2 exact-head comment reports the focused real Go-server and embedded-web Playwright scenario passed on `d44b42e`, including persisted and remote preference changes, mentioned messages, thread replies, and notification navigation.
Findings	1 actionable finding	[P2] Remove the release-owned changelog edit
Security	None	None.

How this fits together

ClickClack turns created messages and thread replies into durable realtime events, then sends push or browser/desktop alerts to eligible users. This PR adds a per-user channel preference decision between event delivery and those alert surfaces.

flowchart LR
  A[Channel message or thread reply] --> B[Store durable event metadata]
  B --> C[Realtime delivery]
  B --> D[Push recipient selection]
  E[Per-channel user preference] --> D
  E --> F[Browser and desktop alert filter]
  C --> F
  D --> G[Pushover alert]
  F --> H[Browser or desktop alert]

Decision needed

Question	Recommendation
Should ClickClack make per-channel all, mentions-only, and muted alerts a supported core preference across web, desktop, Pushover, API, and SDK surfaces?	Sponsor the core preference: Accept the channel-level notification contract after removing release-owned and stale-description material, retaining `all` as the upgrade-safe default.

Why: This is a new persisted user setting and delivery contract rather than a repair to an established behavior; implementation quality alone cannot determine whether that permanent product surface is desired.

Before merge

Remove the release-owned changelog edit (P2) - Do not set the unreleased version or add this feature's release note from a normal feature PR. CHANGELOG.md is release-owned, so this edit creates release-process churn and should be removed from the branch.
Resolve merge risk (P1) - The branch changes persisted notification behavior in both SQLite and PostgreSQL; defaulting existing users to all is compatibility-sensitive even though migration coverage is present.
Resolve merge risk (P1) - Mention IDs become durable event metadata, so the metadata-only reply-event boundary and authorized hydration path must remain intact through final merge review.
Resolve merge risk (P1) - The PR body still says durable reply events carry author/body metadata and names an older head, while the exact-head proof says those fields are intentionally omitted; leaving that conflict can mislead reviewers about the privacy contract.
Resolve merge risk (P1) - The release-owned CHANGELOG.md edit would let a feature PR set release framing and credits outside the release process.
Complete next step (P2) - A maintainer must decide whether the new persisted notification contract belongs in core; the remaining code cleanup is small but does not resolve that product choice.

Findings

[P2] Remove the release-owned changelog edit — CHANGELOG.md:3

Agent review details

Security

None.

Review metrics

Metric	Value	Why it matters
Changed surface	138 files affected; 6,610 additions and 2,123 deletions	The branch spans persistence, generated clients, alert delivery, UI, embedded assets, tests, and unrelated already-landed mainline work, so the final merge view needs a careful scope refresh.
Persistent backends	2 database migrations	SQLite and PostgreSQL both gain event metadata and channel-preference storage, making upgrade behavior a merge-critical concern.

Merge-risk options

Maintainer options:

Remove release-owned and stale PR material (recommended)
Drop the CHANGELOG.md edit and update the PR summary to describe metadata-only reply events plus authorized hydration before any merge decision.
Sponsor the persisted delivery contract
A maintainer should explicitly accept the upgrade default, notification semantics, and durable mention-metadata boundary before landing the new API and storage contract.
Pause if the preference model is not wanted
If channel-level alert policy is not a desired core contract, pause or close this broad feature rather than merge part of its schema and client surface.

Technical review

Best possible solution:

Land a narrowly rebased feature branch that keeps reply events metadata-only, preserves all as the upgrade default, removes the release-owned changelog edit, and documents the final alert/privacy contract accurately.

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

Not applicable as a bug report. The requested capability is new, and the PR supplies a high-confidence exact-head real-server Playwright run that exercises its alert behavior.

Is this the best way to solve the issue?

Unclear. The implementation is comprehensive and has exact-head behavior proof, but only a maintainer can decide whether this new persisted per-channel notification contract belongs in core.

Full review comments:

[P2] Remove the release-owned changelog edit — CHANGELOG.md:3
Do not set the unreleased version or add this feature's release note from a normal feature PR. CHANGELOG.md is release-owned, so this edit creates release-process churn and should be removed from the branch.
Confidence: 0.99

Overall correctness: patch is incorrect
Overall confidence: 0.9

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against 187131ccbbda.

Labels

Label changes:

add proof: sufficient: Contributor real behavior proof is sufficient. An August 2 exact-head comment reports a passing focused real Go-server and embedded-web Playwright scenario covering persisted and live preference changes, message and reply alerts, and click-through navigation.
add status: ⏳ waiting on author: ClawSweeper has contributor-facing work open and is waiting for author action. Sufficient (terminal): An August 2 exact-head comment reports a passing focused real Go-server and embedded-web Playwright scenario covering persisted and live preference changes, message and reply alerts, and click-through navigation.
remove status: 📣 needs proof: Current PR status label is status: ⏳ waiting on author.

Label justifications:

P2: This is a substantial but non-emergency user-facing notification feature that needs a product decision and bounded merge cleanup.
merge-risk: 🚨 compatibility: The PR introduces persisted per-channel preferences and migrations whose defaults affect existing users after upgrade.
merge-risk: 🚨 message-delivery: The feature deliberately suppresses or routes Pushover and browser/desktop alerts based on per-channel mention metadata.
merge-risk: 🚨 security-boundary: Mention IDs are added to durable events, and thread-reply alert text depends on preserving a metadata-only event boundary plus authorized hydration.
rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🦞 diamond lobster and patch quality is 🦐 gold shrimp.
status: ⏳ waiting on author: ClawSweeper has contributor-facing work open and is waiting for author action. Sufficient (terminal): An August 2 exact-head comment reports a passing focused real Go-server and embedded-web Playwright scenario covering persisted and live preference changes, message and reply alerts, and click-through navigation.
proof: sufficient: Contributor real behavior proof is sufficient. An August 2 exact-head comment reports a passing focused real Go-server and embedded-web Playwright scenario covering persisted and live preference changes, message and reply alerts, and click-through navigation.

Evidence

What I checked:

Current main lacks the requested preference layer: Current Pushover delivery selects recipients solely from the message, and the web alert handler accepts only message.created; current main has no channel notification settings endpoint or preference type. (apps/api/internal/httpapi/notifications.go:22, 187131ccbbda)
Existing notification-path provenance: Blame attributes the current server-side notification dispatch path to Shakker's 55da179 commit, making that path the appropriate ownership route for the delivery change. (apps/api/internal/httpapi/notifications.go:22, 55da17970909)
Exact-head behavior proof: The August 2 exact-head comment reports the focused real Go-server and embedded-web Playwright scenario passed on d44b42e, including persisted and remote preference changes, mentioned messages, thread replies, and notification navigation. (tests/e2e/chat.spec.ts:1120, d44b42e9e60c)
Prior durable-event privacy concern is addressed: The exact-head proof states thread.reply_created retains mention IDs but omits author_id and body, then hydrates the authorized message endpoint for alert text; this matches the metadata-boundary repair described in the PR discussion. (apps/api/internal/httpapi/correlation_events_test.go:87, d44b42e9e60c)
Release-owned file remains in the PR diff: The PR changes the unreleased release heading and adds a feature release-note entry in CHANGELOG.md. Repository review policy treats CHANGELOG.md as release-owned, so that edit should not land with this feature branch. (CHANGELOG.md:3, d44b42e9e60c)
Current release boundary: Current main is ahead of the latest tagged release v0.2.1; the feature is not implemented on main and therefore has no release provenance to support closure. (CHANGELOG.md:3, 244dda650fcb)

Likely related people:

Shakker: Current server notification dispatch lines are attributed to the initial notification-path commit and are the direct integration point for preference-aware Pushover delivery. (role: introduced current notification dispatch behavior; confidence: high; commits: 55da17970909; files: apps/api/internal/httpapi/notifications.go, apps/api/internal/store/sqlite/notifications.go, apps/api/internal/store/postgres/notifications.go)
steipete: Recent current-main release and dependency commits touch the release boundary, while the PR discussion supplies the exact-head metadata-boundary and runtime-proof clarification. (role: recent release-surface contributor and exact-head proof contributor; confidence: medium; commits: 5ef70272d82e, 72931b10f083, d4572181d1bc; files: CHANGELOG.md, apps/api/internal/httpapi/notifications.go)

Rank-up moves

Optional improvements that raise the rating; they are not merge blockers.

Remove the CHANGELOG.md edit.
Update the PR description to match the metadata-only thread-reply event design and current head.
Obtain maintainer sponsorship for the per-channel notification contract.

Rating scale

Score	Internal tier	Crab rank	Meaning
6/6	S	🦀 challenger crab	Exceptional readiness
5/6	A	🦞 diamond lobster	Very strong readiness
4/6	B	🐚 platinum hermit	Good normal PR; ordinary maintainer review
3/6	C	🦐 gold shrimp	Useful, but confidence is limited
2/6	D	🦪 silver shellfish	Proof or implementation needs work
1/6	F	🧂 unranked krab	Not merge-ready
N/A	NA	🌊 off-meta tidepool	Rating does not apply

Overall follows the weaker of proof and patch quality.
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.

Workflow

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.

History

Review history (31 earlier review cycles; latest 8 shown)

reviewed 2026-08-01T14:52:59.823Z sha 4608f04 :: needs maintainer review before merge. :: none
reviewed 2026-08-01T17:33:25.658Z sha 4608f04 :: needs maintainer review before merge. :: none
reviewed 2026-08-01T23:47:55.162Z sha 4608f04 :: needs maintainer review before merge. :: none
reviewed 2026-08-02T07:13:44.763Z sha 4608f04 :: needs maintainer review before merge. :: none
reviewed 2026-08-02T12:47:48.764Z sha 4608f04 :: found issues before merge. :: [P1] Preserve the durable event metadata boundary
reviewed 2026-08-02T16:20:34.016Z sha 4608f04 :: needs changes before merge. :: [P1] Keep reply bodies out of durable event payloads
reviewed 2026-08-02T18:21:37.784Z sha 4608f04 :: needs changes before merge. :: [P1] Keep reply bodies out of durable event payloads
reviewed 2026-08-02T21:23:22.268Z sha d44b42e :: needs real behavior proof before merge. :: [P2] Remove the release-owned changelog edit

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 423a41fac0

ℹ️ About Codex in GitHub

Your team has set up Codex to 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 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

jjjhenriksen · 2026-07-26T05:41:38Z

@codex review

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: eb9abbc3c9

ℹ️ About Codex in GitHub

Your team has set up Codex to 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 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

jjjhenriksen · 2026-07-26T05:52:05Z

@codex review

jjjhenriksen · 2026-07-26T05:59:31Z

@codex review

jjjhenriksen · 2026-07-26T06:07:34Z

@codex review

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 3413a00928

ℹ️ About Codex in GitHub

Your team has set up Codex to 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 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

…aw#113) Adds direct characterization coverage for appearance preference normalization, validation, nil preservation, and empty-patch detection. Co-authored-by: Krasimir Kralev <krasi@idrobots.com>

Refreshes application, build, CI, container, and desktop dependencies; aligns pnpm 11.19.0 across every build path; and regenerates the embedded production bundle on current main.

Expose the existing topic model in the web composer and timeline with resilient filtering, draft recovery, and paginated API support. Co-authored-by: PollyBot13 <pollybot13@gmail.com>

Hydrate authorized thread messages for alert text after applying the canonical channel preference, and document the unified conversation-attention model.\n\nCo-authored-by: Jacqueline Henriksen <jjjhenriksen@gmail.com>

steipete · 2026-08-02T21:30:54Z

Exact-head proof for d44b42e9e60cef731aff3073d35eb823265ae592 after the metadata-boundary repair:

pnpm check passed, including Go, TypeScript, desktop, lint, formatting, generated-web consistency, and migration/store coverage.
go test ./apps/api/internal/store/... ./apps/api/internal/httpapi/... passed for SQLite, PostgreSQL, HTTP authorization, event metadata, and notification preference paths.
pnpm generate:sqlc completed cleanly and the production web/SDK bundle was regenerated and embedded.
The focused real-server browser scenario passed: pnpm exec playwright test tests/e2e/chat.spec.ts --grep "channel preferences filter browser notifications outside the active conversation" --reporter=line → 1 passed (11.3s).

That scenario exercised muted, mentions, and all; persisted and remote preference changes; ordinary and mentioned background messages; thread replies; and click-through navigation. It also asserted that thread.reply_created retains mentioned_user_ids but omits both author_id and body, while the browser subsequently fetched the authorized message endpoint and displayed the real reply text.

Exact-head GitHub verification is green:

CI (Go, TypeScript, Docker, full Playwright): https://github.com/openclaw/clickclack/actions/runs/30767616242
Desktop (macOS, Windows, Linux): https://github.com/openclaw/clickclack/actions/runs/30767616260

steipete · 2026-08-02T21:30:55Z

@clawsweeper re-review

Exact-head after-fix runtime proof is now attached above for d44b42e9e60cef731aff3073d35eb823265ae592, including the metadata-only durable reply event and authorized notification hydration path.

clawsweeper · 2026-08-02T21:30:57Z

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: when the review finishes, ClawSweeper will create the durable review comment if needed or update the existing comment in place.

Re-review progress:

State: Complete
Detail: The item is closed; no stale verdict was published.
Run: https://github.com/openclaw/clawsweeper/actions/runs/30768430863
Updated: 2026-08-02T21:41:13.406Z

jjjhenriksen marked this pull request as ready for review July 26, 2026 03:38

chatgpt-codex-connector Bot reviewed Jul 26, 2026

View reviewed changes

jjjhenriksen force-pushed the codex/mentions-notifications branch from 423a41f to eb9abbc Compare July 26, 2026 05:38

clawsweeper Bot added rating: 🐚 platinum hermit Good normal PR readiness with ordinary maintainer review expected. and removed rating: 🦐 gold shrimp Decent PR readiness signal, but merge confidence is limited. labels Jul 26, 2026

chatgpt-codex-connector Bot reviewed Jul 26, 2026

View reviewed changes

Comment thread apps/web/src/ChatApp.svelte

Comment thread apps/web/src/ChatApp.svelte

Comment thread apps/api/internal/store/sqlite/sqlc/queries.sql Outdated

jjjhenriksen force-pushed the codex/mentions-notifications branch from eb9abbc to 62b88b8 Compare July 26, 2026 05:51

jjjhenriksen force-pushed the codex/mentions-notifications branch from 62b88b8 to 668fe88 Compare July 26, 2026 05:56

jjjhenriksen force-pushed the codex/mentions-notifications branch from 668fe88 to 3413a00 Compare July 26, 2026 06:06

chatgpt-codex-connector Bot reviewed Jul 26, 2026

View reviewed changes

Comment thread apps/api/internal/store/sqlite/sqlc/queries.sql

Comment thread apps/api/internal/store/types.go

jjjhenriksen added 2 commits July 29, 2026 12:57

feat: add channel mention notifications

519d753

fix: address mention notification review findings

85a9a94

jjjhenriksen force-pushed the codex/mentions-notifications branch from 3413a00 to 85a9a94 Compare July 29, 2026 20:11

test: cover channel notification settings API

4608f04

KrasimirKralev and others added 3 commits August 2, 2026 00:14

test(store): cover appearance-preferences patch normalization (opencl…

3205c07

…aw#113) Adds direct characterization coverage for appearance preference normalization, validation, nil preservation, and empty-patch detection. Co-authored-by: Krasimir Kralev <krasi@idrobots.com>

chore(deps): update dependencies (openclaw#139)

5ef7027

Refreshes application, build, CI, container, and desktop dependencies; aligns pnpm 11.19.0 across every build path; and regenerates the embedded production bundle on current main.

chore: prepare 0.2.2 release

72931b1

PollyBot13 and others added 6 commits August 2, 2026 14:04

feat(web): expose message topics (openclaw#121)

187131c

Expose the existing topic model in the web composer and timeline with resilient filtering, draft recovery, and paginated API support. Co-authored-by: PollyBot13 <pollybot13@gmail.com>

feat: add channel mention notifications

649e986

fix: address mention notification review findings

cb4e8c1

test: cover channel notification settings API

da2b317

fix(notifications): preserve metadata-only events

d457218

Hydrate authorized thread messages for alert text after applying the canonical channel preference, and document the unified conversation-attention model.\n\nCo-authored-by: Jacqueline Henriksen <jjjhenriksen@gmail.com>

chore: retain contributor branch history

d44b42e

steipete merged commit ca3c86f into openclaw:main Aug 2, 2026
18 checks passed

jjjhenriksen deleted the codex/mentions-notifications branch August 2, 2026 21:40

steipete mentioned this pull request Aug 2, 2026

docs: reconcile conversation feature guides #141

Merged

Uh oh!

Conversation

jjjhenriksen commented Jul 24, 2026 • edited by steipete Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Real behavior proof

Validation

Uh oh!

jjjhenriksen commented Jul 24, 2026

Uh oh!

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

Uh oh!

Uh oh!

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

Uh oh!

ClawSweeper review

What this changes

Merge readiness

Review scores

Verification

How this fits together

Decision needed

Before merge

Findings

Security

Review metrics

Merge-risk options

Technical review

Labels

Evidence

Rank-up moves

Rating scale

Workflow

History

Uh oh!

chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

jjjhenriksen commented Jul 26, 2026

Uh oh!

chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

Uh oh!

Uh oh!

Uh oh!

jjjhenriksen commented Jul 26, 2026

Uh oh!

jjjhenriksen commented Jul 26, 2026

Uh oh!

jjjhenriksen commented Jul 26, 2026

Uh oh!

chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

Uh oh!

Uh oh!

steipete commented Aug 2, 2026

Uh oh!

steipete commented Aug 2, 2026

Uh oh!

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

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

jjjhenriksen commented Jul 24, 2026 •

edited by steipete

Loading

clawsweeper Bot commented Jul 24, 2026 •

edited

Loading

clawsweeper Bot commented Jul 26, 2026 •

edited

Loading

clawsweeper Bot commented Aug 2, 2026 •

edited

Loading