[StiensWout]

Pi extensions can emit explicitly visible custom messages, but T3 currently drops them. A command that returns only a custom result completes with no readable output.

Map active-turn display: true string/text-block messages to the existing completed system notice at message_end. Keep customType provenance, ordering and distinct identities for repeated results; keep hidden context and details out of the work log. This reuses existing rendering on all clients and adds no UI, schema or settings. Idle startup, history imports, images and native TUI renderers remain outside scope.

This is proposed as a focused correction of an existing Pi visible-message contract, not claimed prior maintainer approval. Relevant Pi contract: custom messages. It does not duplicate #27556 widgets/status, #32079 background children, or #28798/#17891 plain-input settlement fixes. Existing slash-command semantics suffice here.

Validation:

• Public adapter tests failed before the fix and pass after it: strict visibility controls, string/text arrays, repeat identity, mixed assistant/custom/assistant ordering, and command-only completion. Additional mutations prove final content is read at message_end and missing customType has no invented prefix.
• 125 related tests passed; final check:changed passed format, lint, knip, nine affected package typechecks and both selected test files. No repo-wide checks run.
• Real offline Pi 1.5.0 extension command, with isolated agent home and no credentials/model requests, emitted the expected protocol.
• One integrated real-client pass used that isolated Pi CLI: three separate completed notices, multiline text preserved, hidden content/details absent, no assistant message, activeRunId null. Notices persisted across client reload. Existing system_notice presentation is unchanged.

Standard workflow used because this changes stateful protocol translation. Separate builder, trim, council, evidence and proof-audit runs completed. Final audit: no remaining proof gaps. Local cubic: one P2 nit about unbounded text duplicated in notice title/message; deferred to the shared emitSystemNotice helper, which already behaves this way for notifications. Other nonblocking nits: empty customType gives a [] prefix; the mixed-order fixture could be written without its small loop. No blocker or should findings remain.

Council review

Reviewer	Round 1
GPT 6.1 Sol	9.5/10
Claude Opus 5.5	9/10

User-approved two-member council exception continued after Grok/Muse quota limits. Later changes only strengthened proof assertions and normalized coauthor metadata; adapter behavior stayed unchanged. Evidence needed a second gap-only run and the second audit passed.

Created with GPT 6.1 Sol (lead, builder, reviewer, evidence, proof auditor) and Claude Opus 5.5 (trim/simplify, reviewer) in T3 Code through the Codex and Claude Agent harnesses.

[macroscopeapp]

Approvability

Verdict: Approved at b11fc83

Macroscope's review found this PR approvable — Explicitly visible Pi extension messages now appear as work-log notices. Hidden messages and nontext content remain excluded, and existing assistant handling is unchanged.

^{You can add or adjust custom eligibility rules. Learn more.}

[coderabbitai]

No actionable comments were generated in the recent review.

Walkthrough

The Pi adapter now emits displayed, nonblank custom messages as system notices. Tests cover accepted and ignored content, repeated notices, and custom notices between assistant messages.

Changes: Pi Custom Message Notices

Layer / File(s)	Summary
Custom notice handling packages/provider-pi/src/server/adapter.ts, packages/provider-pi/src/server/adapter.test.ts	message_end emits displayed custom messages with nonblank text as system notices, with an optional custom-type prefix. Tests verify content filtering, distinct notice ordering, and that assistant messages retain their identities.

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Bug fix

Possibly related issues

• pingdotgg/t3code#17363: This PR adds handling for displayed custom messages, but the issue’s display: false subagent-status behavior remains outside the changes.

Suggested labels: bugfix

Suggested reviewers: juliusmarminge

Merge Risk: Minimal · up to b11fc

The separate test protects active-turn ordering and assistant identities. No identified issue needs resolution before merging.

Pre-merge checks: 4

Check name	Status	Explanation
Title check		The title clearly describes the Pi extension message fix.
Description check		The description covers the problem, change, scope, verification, and agent use. It omits the template headings and does not fully explain why the fix qualifies without prior approval.
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.

Finishing Touches

Generate unit tests (beta)

• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Recent review info

Run configuration

• Source mode: Auto
• Repository: pingdotgg/t3code
• Branch: main
• File: .coderabbit.config.ts
• Commit: 4c3a9d5
• Layers: Repository TS config
• Review profile: CHILL
• Plan: Advanced
• Run ID: 48efe84d-d772-45fa-9603-16c5785e9b0d

Commits

Reviewing files that changed from the base of the PR and between 4c3a9d5 and b11fc83.

Files selected for processing: 2

• packages/provider-pi/src/server/adapter.test.ts
• packages/provider-pi/src/server/adapter.ts

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 6 remain after this review.

[maria-rcks]

Note

Written by gpt-6.1-sol on behalf of Maria

Verified in a real dev environment

Verified unchanged head b11fc8368e7a17f21c60ca0cb06c90ca0e61f567 on a Linux Boat VM. Installed dependencies in a separate github/main worktree (1c65ad032e) and on the exact PR head. Ran one isolated dev server at a time and drove the web app using repository Playwright and /usr/bin/google-chrome.

Created a project and threads through the app, pointing at a real git repository. A real Pi 1.5.2 extension command, /repo-status, runs git to read its branch and working tree, then emits two identical visible string messages, one visible text-block message, hidden context, private details, and an ordinary notification. No replay provider or mocked protocol was used.

• Main: command completed, but only the ordinary notification appeared. All three visible custom messages were missing.
• PR: all three appeared in order as separate completed notices. Expansion preserved line breaks. Hidden context and private details were absent. Notices survived reload.
• Nearby behavior: the ordinary Pi notification still appeared; a subsequent real Pi model turn ran git and returned verification; real Codex gpt-6.1-sol turns on both revisions returned the actual branch and clean working tree.

Read-only checks of the running servers' persisted projections:

main /repo-status: completed; system_notice=1 (ordinary notification only)
PR /repo-status:   completed; custom_notices=3; distinct_items=3; distinct_nodes=3
PR custom ordinals: 1000003, 1000004, 1000005; all completed
PR activeRunId: null
PR normal Pi model turn: completed; assistant reply: verification
PR Codex gpt-6.1-sol turn: completed; branch: verification; working tree clean

Blacksmith vp run check:changed 4c3a9d58184f20bd76833bd599c3544d2c09e3eb passed format, lint, both knip passes, nine package typechecks, and 122 tests across two files. Existing CI has no failing or pending checks. No code changes or pushes were needed.

Not verified

Native iOS/Android clients, Electron shell behavior, macOS/Windows, and remote relay/tunnel connections were not exercised on this Linux web pass. Idle startup messages, history imports, images, and native TUI renderers remain outside this PR's stated scope. The runtime extension did not exercise every malformed protocol case; the adapter suite covers strict visibility and nontext filtering.