I think this is more of a bug in my code (and possibly rich) versus rich-click, but I'm documenting my debugging here in case this helps anyone else.

My tool has a few subcommand groups that manually print the help like so:

import rich_click as click
from rich.console import Console
console = Console()

@click.group(name="subcmd_example", invoke_without_command=True)
@click.pass_context
@click.option(
    "--version", is_flag=True, default=False, help="Show subcmd version and exit"
)
def subcmd_example(ctx: click.Context, version: bool):
    if ctx.invoked_subcommand is None:
        if version:
            ...
        else:
            console.print(ctx.get_help())

With rich-click 1.8 this works as expected. After upgrading to rich-click 1.9.7 (also tested with 1.9.0), with the latest versions of click (8.3.1), rich (14.3.2, released earlier this week), and python (3.14.3) on Windows 11, this hangs in console.print().

I made a few observations while debugging:

1. Replacing console.print() with a regular print() works as expected (including rich formatting)
2. Downgrading rich-click to 1.8.9 works as expected (with console.print())
3. Downgrading rich to 14.3.1 or 14.2.0 causes the help to print without hanging, but with severely broken formatting that includes ANSI escape sequences
   • Unsurprisingly, the hang in rich 14.3.2 appears to be related to the code in cells.py changed by that update. The split_graphemes() function has a while index < codepoint_count loop where neither of those values ever change when it calls the updated get_character_cell_size() function. rich 14.3.2 updated this function to return 0 for certain codepoint values, including for ANSI escape character \x1b, which is causing the hang. In rich 14.3.2, this function returned 1 for character \x1b, continuing to print, but with ANSI codes printed as mentioned above.
4. Printing the subcommand help by explicitly passing in a --help flag is unaffected and works as expected.
5. In rich-click 1.8.9, ctx.get_help() printed the help and returned an empty string, while in 1.9.x it returns the help string (with ANSI codes) and does not directly print anything. I think the old behavior was inconsistent with the click API and the new behavior makes more sense, but I did not realize that it would return an ANSI string incompatible with Console.print().

Overall this might be more of an issue with my code and/or rich vs. rich-click, and it appears that I should not be passing the output of ctx.get_help() to a rich Console object vs the built-in print(), but this surprised me as it was working as expected prior to 1.9.