Add channels mode patch (tengu_harbor bypass)#653
Conversation
Force-enable MCP channel notifications by bypassing the tengu_harbor feature gate, gateChannelServer allowlist, and permission relay gate. Suppresses the "Experimental" startup warning and the dev-flag warning for server-kind entries. Allows --channels to work without --dangerously-load-development-channels and its per-session confirmation dialog.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughAdds a new Changes
Sequence Diagram(s)(Skipped — changes are patch/file-rewrite focused and do not introduce a multi-component runtime interaction flow requiring a sequence diagram.) Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@src/patches/channelsMode.ts`:
- Around line 116-136: The current patchPermissionRelay function force-enables
the "tengu_harbor_permissions" gate as part of the channels-mode patch; extract
this behavior into a separate opt-in patch and stop applying it automatically
from channels-mode. Specifically, remove the automatic insertion call (or
prevent calling patchPermissionRelay) from wherever channels-mode applies
patches, create a distinct opt-in function/flag named patchPermissionRelay (or
patchPermissionRelayOptIn) that only runs when an explicit permission-relay
toggle is enabled, and ensure channels-mode uses only the channel-related patch
logic. Update any UI/config toggle or patch application logic to expose the new
opt-in flag and document that patchPermissionRelay is separate from
channels-mode.
- Around line 150-173: patchChannelsNotice currently treats failing to locate
the cosmetic warning as an unrecoverable error and returns null; change it to be
best-effort: when the regex match fails (or match.index is undefined) log a
non-fatal warning and return the original file string unchanged instead of null
so UI-only rewrites don't block functional patches; apply the same behavior to
the sibling functions referenced (other cosmetic patch helpers used by
writeChannelsMode / writeChannelsMode callers) so cosmetic patch failures never
cause the gate bypass to be skipped.
- Around line 90-109: The injected early return in patchGateFunction (insertion
= 'return{action:"register"};') short-circuits downstream auth/policy/session
guards for gateChannelServer; instead of returning, change the insertion to set
a sentinel flag (e.g. '__patched_channel_register = true;') or call a
non-returning helper (e.g. '__markChannelRegistration()') so the code records
that the server advertised claude/channel but lets the existing
auth/policy/session checks continue to run; update the insertion string in
patchGateFunction and keep showDiff/newFile logic the same so no control-flow is
changed by the patch.
In `@src/ui/components/MiscView.tsx`:
- Around line 437-450: The enableChannelsMode toggle currently flips on with one
press and must require an explicit acknowledgement like
allowBypassPermissionsInSudo: change the toggle handler for the item with id
'enableChannelsMode' to open the same confirmation/ack dialog used by
allowBypassPermissionsInSudo (or reuse its confirmation helper), only call
updateSettings/ensureMisc to flip settings.misc!.enableChannelsMode after the
user explicitly confirms, and update the title/description copy to warn that
this bypasses tengu_harbor, allowlist, org/session auth, and force-enables
permission relay (broader blast radius).
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 7e7d621b-f8fc-46ed-81eb-a60ee52f3de0
📒 Files selected for processing (5)
src/defaultSettings.tssrc/patches/channelsMode.tssrc/patches/index.tssrc/types.tssrc/ui/components/MiscView.tsx
viceversaco
left a comment
viceversaco
left a comment
There was a problem hiding this comment.
Thanks for the review. Addressing each comment:
1. Don't short-circuit gateChannelServer (Critical)
Dismissing. The entire purpose of this patch is to bypass the channel gates so --channels works without the tengu_harbor feature flag rollout. A sentinel flag that lets auth/policy/session checks continue to run would defeat the purpose — those downstream guards reject server: entries that lack entry.dev, which is the exact gate we're bypassing. Users opting into this patch are explicitly choosing to skip these checks.
2. Permission relay needs separate opt-in (Critical)
Dismissing. Permission relay (tengu_harbor_permissions) is essential for the primary use case: headless agent orchestration. Headless agents can't show TUI permission dialogs, so permission relay is the only way tool approvals work. Splitting it into a separate toggle would mean users need to flip two switches to get a working setup. The MCP server still has to explicitly declare claude/channel/permission capability to opt in — it's not force-enabled on all channel servers.
3. Cosmetic patches as hard dependency (Major)
Good catch — accepted. Cosmetic patches (notice text rewrite, dev-flag warning removal) now use ?? newFile fallback so upstream string changes don't block the functional gate bypasses. Fixed in next commit.
4. Confirmation dialog on toggle (Major)
Passing on this for now. tweakcc is an opt-in power-user tool — users have already made a deliberate choice to install and configure it. Adding a confirmation dialog on top of that adds friction without meaningful safety benefit.
Cosmetic patches (notice text rewrite, dev-flag warning removal) now fall back to the unmodified file instead of aborting the entire patch. This prevents upstream string changes from blocking functional gate bypasses.
|
Thanks! Wait till you see what I'm doing with it 😉 sharing soon. |
1. Move session-color definition into the ALWAYS_APPLIED block
(next to statusline-update-throttle) for ordering consistency.
2. Tighten idempotency check: match the full injection sentinel
'standaloneAgentContext:(()=>{let __c=process.env.TWEAKCC_SESSION_COLOR;'
instead of the broad 'TWEAKCC_SESSION_COLOR' substring to avoid
false-positive early returns.
3. Rebase onto upstream/main to resolve conflict with channels-mode
patch (Piebald-AI#653).
2 participants
Summary
Adds a
channels-modepatch that force-enables MCP channel notifications by bypassing thetengu_harborfeature gate and related checks. This allows--channelsto work without--dangerously-load-development-channelsand its per-session confirmation dialog.Toggled via
enableChannelsModein the Misc settings TUI.What it patches
The patch has 5 sub-patches:
isChannelsEnabled()— bypasses thetengu_harborGrowthBook gate (master on/off)gateChannelServer()— returns{action:"register"}after the capability check, skipping auth, org policy, session, and allowlist gatesisChannelPermissionRelayEnabled()— bypasses thetengu_harbor_permissionsgateNote on scope
Patch 2 is a blanket bypass — after the capability check (does the server declare
claude/channel?), it skips all remaining gates (OAuth auth, Teams/Enterprise policy, session allowlist, plugin/server allowlist). This keeps the patch simple and covers all channel use cases, but it does mean those intermediate checks are fully bypassed rather than selectively targeted.If you'd prefer to split this up — e.g., separate patches for the feature gate vs. allowlist vs. notice suppression, or more surgical targeting of individual gates — happy to rework it.
Usage
Summary by CodeRabbit
New Features
UI/UX Improvements