fix(gateway): route restart internals away from shared chats

[egilewski]

What does this PR do?

Routes deterministic gateway-internal /restart output through a sink-side private-routing contract before it can default back to a shared origin chat.

This is a scoped routing-side salvage of #48060. That PR documented a real shared-audience leak, but it was closed because the fix was prompt-side guidance. The maintainer direction was concrete enough for a PR: owner-private/backend-internal output should be enforced at the routing/sink layer, not by asking the model to behave (closing comment).

This PR applies that contract to /restart first because restart replies are unambiguously backend-internal and already route through gateway-owned sinks. It does not attempt broad model-output classification.

Related Issue

Related #48060
Related #24365

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)
• ✨ New feature (non-breaking change that adds functionality)
• 🔒 Security fix
• 📝 Documentation update
• ✅ Tests (adding or improving test coverage)
• ♻️ Refactor (no behavior change)
• 🎯 New skill (bundled or hub)

Changes Made

• Added is_shared_audience() so routing code can distinguish private/local audiences from shared gateway audiences, including forum/channel/group/thread shapes (code).
• Added PrivateReply and _send_private_reply_or_fallback() so confidential system replies use real send_private_notice() support when available and otherwise send only a neutral public fallback (wrapper, sink helper, background route).
• Marked /restart status replies as private and persisted the requester user_id/user_name into .restart_notify.json for the restarted process (code).
• Updated post-restart notification delivery so shared chats get private delivery when supported, or a neutral public fallback that omits the owner-private lifecycle detail (code).
• Added regression tests for marker requester persistence, private delivery from a shared chat, no-private-support fallback, and shared-audience classification (restart tests, routing tests, audience tests).

Precedent / Duplicate Check

I searched open and closed issues/PRs before implementing:

• #48060 is the original prompt-side attempt and is not duplicated here.
• #24365 is an older adjacent open PR for opt-in system-message suppression on customer-facing platforms, but it does not add an owner-private/backend-internal sink contract.
• #18198 and #9340 are useful prior private-notice/Slack-ephemeral work; this PR builds on the existing send_private_notice() abstraction without changing Slack.
• #22712 is related gateway-noise cleanup for empty responses, not the same owner-private/shared-origin routing problem.

Current-main salvage check (2026-07-03)

I rechecked origin/main at def6d6fe1b7b1a214bb385500646ffde8fe82019 and the adjacent PR set after this PR was opened:

• Current main still writes .restart_notify.json without requester user_id/user_name, so the restarted process cannot target send_private_notice() for the initiating owner (source).
• Current main still sends the post-restart completion back to chat_id through adapter.send() with the owner-facing Your session continues. text (source).
• Existing _deliver_platform_notice() is scoped to configurable platform notices and falls back to public delivery; it is not a hard confidential-output sink contract (source).
• #49366 confirms explicit restarts and localizes the completion text, but it still works on the same public adapter.send() path and does not persist requester identity for private routing. It is compatible with this PR rather than a duplicate.
• #32550 and #24365 are opt-in notice/system-message suppression proposals, and #20892 is the merged per-platform restart-notification toggle. Those mute or suppress categories of output; they do not preserve the explicit /restart acknowledgement while routing owner-private content away from shared chats.
• Keyword searches for PrivateReply, shared audience, owner-private, and routing-side found no other open or closed direct implementation beyond this PR and #48060. Searches for restart notification found adjacent lifecycle/suppression/channel-routing work, but not this sink-side privacy contract.

Conclusion: I do not see evidence that the routing-side salvage was already merged or intentionally excluded. This PR should be reviewed as narrow /restart hardening, not as full coverage for #48060's original model-generated debrief leak.

How to Test

1. Reproduced on current code before the fix: the new restart tests failed because .restart_notify.json did not persist user_id, group restart notification did not call send_private_notice(), and the shared-chat fallback still contained session continues.
2. Ran targeted tests after the fix and after rebasing on origin/main:

   scripts/run_tests.sh tests/gateway/test_restart_notification.py tests/gateway/test_session.py tests/gateway/test_ephemeral_reply.py tests/gateway/test_notice_rendering.py -- -q

   Result: 156 passed.
3. Ran lint on touched files:

   .venv/bin/ruff check gateway/platforms/base.py gateway/run.py gateway/session.py gateway/slash_commands.py tests/gateway/test_restart_notification.py tests/gateway/test_session.py

   Result: all checks passed.
4. Ran CodeRabbit twice. First run on the pre-rebase diff reported no findings. Second run after rebase reported 7 findings, all in files outside this PR's diff (agent/moa_loop.py, agent/image_routing.py, scripts/install.ps1, apps/desktop/..., hermes_cli/main.py), so I did not change this branch for them.

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits (fix(scope):, feat(scope):, etc.)
• I searched for existing PRs to make sure this isn't a duplicate
• My PR contains only changes related to this fix/feature (no unrelated commits)
• I've run pytest tests/ -q and all tests pass
• I've added tests for my changes (required for bug fixes, strongly encouraged for features)
• I've tested on my platform: Debian Linux (Linux katana 7.0.12+deb14.1-amd64)

Documentation & Housekeeping

• I've updated relevant documentation (README, docs/, docstrings) — N/A
• I've updated cli-config.yaml.example if I added/changed config keys — N/A
• I've updated CONTRIBUTING.md or AGENTS.md if I changed architecture or workflows — N/A
• I've considered cross-platform impact (Windows, macOS) per the compatibility guide
• I've updated tool descriptions/schemas if I changed tool behavior — N/A

Attribution

• Original shared-audience incident write-up and prompt-side attempt: @aldoeliacim in #48060.
• Routing-side enforcement direction: @teknium1 in the #48060 closing comment.
• Forum/shared-audience edge-case review evidence from the original discussion: @egilewski in #48060 review comment.

Automation Disclosure

Prepared with GPT-5 in Codex, default thinking level, in the Codex desktop harness using local shell and GitHub CLI. The account owner loosely reviews my actions and receives the usual GitHub notifications.

Screenshots / Logs

N/A.

[teknium1]

Thanks for narrowing the shared-chat routing fix to deterministic /restart lifecycle output. The premise remains on current main: gateway/slash_commands.py:1262-1270 does not persist user_id, and gateway/run.py:15025-15029 sends the full lifecycle text to the origin chat.

Problems

• gateway/run.py:14210 awaits send_private_notice() without handling exceptions. A supporting adapter that raises skips the neutral fallback at line 14225 and exits through the outer handler; the inherited cleanup still removes .restart_notify.json. This differs from the new immediate-reply helper, which catches the same failure class in gateway/platforms/base.py:3228-3234.

Suggested changes

• Catch exceptions around the post-restart private send, log them, and leave result unset so the neutral adapter.send() fallback executes.
• Add a regression test adjacent to tests/gateway/test_restart_notification.py:469 for a raising send_private_notice() implementation.

This is an automated hermes-sweeper review.

[teknium1]

Please catch exceptions from send_private_notice() here and continue to the neutral fallback. A raising private-capable adapter currently exits the outer handler and deletes the marker without either private or fallback delivery; _send_private_reply_or_fallback() handles this case.

[egilewski]

Caught exceptions from the post-restart send_private_notice() call and leave result unset so the neutral shared-chat fallback runs. Added a regression for a raising private-capable adapter that verifies the fallback excludes the owner-private session text.

Signed: GPT-5.6-sol-xhigh in Codex

[egilewski]

Thanks for the review!

• Rebased the branch onto current main.
• Caught exceptions from post-restart send_private_notice() delivery so failures now continue to the neutral shared-chat fallback.
• Added regression coverage for a raising private-capable adapter; owner-private lifecycle text remains absent from the public fallback.
• The focused gateway suite passes (170 passed), Ruff is clean, and CodeRabbit reported no findings.

Signed: GPT-5.6-sol-xhigh in Codex