fix: make userMessageDisplay opt-in to prevent CC 2.1.6+ input bug

[treygoff24]

1 ## Summary
2
3 The userMessageDisplay patch causes an "insta-ESC" bug on Claude Code 2.1.6 where user input is immediately cancelled/escaped. This makes Claude Code completely unusable when the patch is applied.
4
5 ### Root Cause
6
7 The patch modifies the component structure for rendering user messages (wrapping in a Box component, changing the React element tree). This structural change appears to interfere with input handling in CC 2.1.6+.
8
9 ### The Fix
10
11 Make userMessageDisplay opt-in instead of always-on:
12
13 - Add enabled?: boolean field to UserMessageDisplayConfig type
14 - Default to enabled: false in DEFAULT_SETTINGS
15 - Only apply the patch when enabled === true (strict equality check)
16 - Show a helpful migration warning for users who have custom styling configured but haven't explicitly enabled the feature
17
18 This allows users to continue using all other tweakcc features (themes, thinking verbs, etc.) safely, while making userMessageDisplay opt-in for those willing to test it on their CC version.
19
20 ### Why enabled === true (not !== false)
21
22 Existing user configs won't have the enabled key, so:
23 - undefined !== false → true ❌ would still apply broken patch
24 - undefined === true → false ✅ safely skips the patch
25
26 ## Test Plan
27
28 - [x] TypeScript compiles without errors
29 - [x] All existing tests pass (132 passed)
30 - [x] Tested on Claude Code 2.1.6 - confirmed working
31 - [x] Other tweakcc features (themes, thinking verbs) still work correctly
32 - [x] Migration warning displays for users with custom styling
33
34 ## Files Changed
35
36 - src/types.ts - Added enabled?: boolean to UserMessageDisplayConfig
37 - src/defaultSettings.ts - Set enabled: false as default
38 - src/patches/index.ts - Check for explicit opt-in + migration warning
39
40 ---
41
42 🤖 Generated with Claude Code

Summary by CodeRabbit

• Bug Fixes

  • User message display customization is now disabled by default to improve compatibility. Enable it explicitly in settings if custom styling is needed.

• Improvements

  • Added warning notifications alerting users when message customization is configured but disabled.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

📝 Walkthrough

Walkthrough

This PR introduces an opt-in mechanism for user message display customization by adding an enabled boolean field to the userMessageDisplay configuration. The feature is disabled by default, with a warning logged when custom styling exists but remains disabled due to compatibility concerns.

Changes

Cohort / File(s)	Summary
Configuration Schema src/defaultSettings.ts, src/types.ts	Added optional enabled: boolean property to userMessageDisplay configuration, establishing default disabled state and extending interface type definitions.
Patch Application Logic src/patches/index.ts	Replaced unconditional userMessageDisplay customization with opt-in gating. Now only applies when enabled === true, and logs a warning when custom styling is detected but disabled.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

Possibly related PRs

• Fix all patches for CC 2.1.2 #352: Updates userMessageDisplay patch implementation and formatting — directly related as both PRs modify user message display patching mechanisms.

Suggested reviewers

• bl-ue

Poem

🐰 A toggle flips, the feature sleeps,
Until the user dares to leap.
"Enabled true," they softly sing,
And customization spreads its wing! ✨

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly summarizes the main change: making userMessageDisplay opt-in to address a CC 2.1.6+ input bug, which is precisely what the changeset implements.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

• 📝 Generate docstrings

---

🧹 Recent nitpick comments

src/patches/index.ts (1)

566-580: Consider including padding/fitBoxToContent in custom styling detection.

The hasCustomStyling check omits paddingX, paddingY, and fitBoxToContent. While these are less commonly customized, users who only changed padding would not see the migration warning.

♻️ Optional: More complete custom styling detection

     const hasCustomStyling =
       displayConfig.format !== ' > {} ' ||
       (displayConfig.styling?.length ?? 0) > 0 ||
       displayConfig.foregroundColor !== 'default' ||
       displayConfig.backgroundColor !== null ||
-      displayConfig.borderStyle !== 'none';
+      displayConfig.borderStyle !== 'none' ||
+      displayConfig.paddingX !== 0 ||
+      displayConfig.paddingY !== 0 ||
+      displayConfig.fitBoxToContent !== false;

📜 Recent review details

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 80c4ca6 and 20cf7ba.

📒 Files selected for processing (3)

• src/defaultSettings.ts
• src/patches/index.ts
• src/types.ts

🧰 Additional context used

🧬 Code graph analysis (1)

src/patches/index.ts (1)

src/patches/userMessageDisplay.ts (1)

• writeUserMessageDisplay (55-234)

🔇 Additional comments (3)

src/types.ts (1)

80-102: LGTM!

The optional enabled?: boolean property correctly supports the opt-in mechanism. Existing configurations lacking this field will have enabled as undefined, and the strict equality check (=== true) in the patch logic ensures backward compatibility by skipping the patch unless explicitly enabled.

src/defaultSettings.ts (1)

733-744: LGTM!

Setting enabled: false as the default correctly implements the opt-in mechanism. This ensures the userMessageDisplay patch is disabled by default for all new configurations, preventing the "insta-ESC" bug on CC 2.1.6+.

src/patches/index.ts (1)

543-565: LGTM!

The opt-in mechanism is correctly implemented:

• Strict equality check (displayConfig?.enabled === true) ensures the patch is skipped when enabled is undefined or false
• The local displayConfig variable improves readability compared to repeated config.settings.userMessageDisplay accesses

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[bl-ue]

Hi @treygoff24! The "inst-esc" issue you described sounds exactly like what happens when tweakcc accidentally breaks some Claude Code internals. It's because there's actually an error occurring when you send a message, but Claude Code doesn't normally display. To see the actual error, will you please

1. run claude --debug (with your tweakcc patches applied),
2. open the log file that will be indicated in the output,
3. send a message to trigger the error,
4. look for a JavaScript error towards the end of the log file, and
5. send that log file here?