Following the discussion at #10852, I believe this is the right default. I'm willing to continue to revisit this decisions, but Ghostty 1.3 is around the corner and I don't think such a change like this should be pushed into it. This was proposed before but I wanted to wait to iron out any bugs here and I think we have. Namely we identified one bug where we were accidentally overriding our _default_ palette which shouldn't happen. But now that it has sat awhile and we've gathered enough feedback, I'm willing to commit to it. In general, we got **very little negative feedback.** The linked discussion shows very little activity relative to other more controversial changes we've made. It has basically 1 upvote with around 5 participants whereas our most popular or breaking features/bugs have had at least dozens if not over a hundred. I think this shows that this change isn't that disruptive, either because the colors work fine or because not that many things use the 256-color palette (probably the latter moreso but a mix for sure). For that reason, I do think revisiting this at some point is warranted. I think palette generation is best left as a _theme author_ tool. A Ghostty color theme could include `palette-generate=true` if it wants to customize the 256-color palette more easily. Of course, end users can as well anytime. Another part of my reasoning is that TUI programs who want this behavior can already achieve it themselves by mixing dark/light theme detection via CSI 996 (https://contour-terminal.org/vt-extensions/color-palette-update-notifications/) with OSC 4/10/11 color query and change sequences, both of which are decently supported in the terminal ecosystem and fully supported in Ghostty. I'm also open to considering some kind of new sequence to make this easier for TUIs (probably a mode) where they can opt-in to palette generation plus "harmonius" palettes (see `palette-harmonius`) and Ghostty does it on demand then. I think that'd solve the legacy vs new TUI argument where legacy programs can continue to make assumptions about the palette and new programs can opt-in to a more dynamic palette without having to do a lot of work themselves. cc @jake-stewart