feat: update default (#4076)

Changes:
- Default model and docs now use gpt-5-codex. 
- Disables the GPT-5 Codex NUX by default.
- Keeps presets available for API key users.

codex-rs/tui/src/chatwidget/snapshots/codex_tui__chatwidget__tests__binary_size_ideal_response.snap

@@ -1,6 +1,5 @@
 ---
 source: tui/src/chatwidget/tests.rs
-assertion_line: 648
 expression: visible_after
 ---
 > I’m going to scan the workspace and Cargo manifests to see build profiles and
@@ -10,6 +9,14 @@ expression: visible_after
   └ List ls -la
     Read Cargo.toml
 
+• I'm reviewing the workspace's release profile, which has settings like
+  lto=fat, strip=symbols, and codegen-units=1 to reduce binary size. However, it
+  seems that "strip = symbols" only removes symbols, not debug information. In
+  Rust 1.73+, both "symbols" and "debuginfo" stripping options are available. I
+  should check whether using these results in a smaller binary. I’ll also skim
+  through crates for heavy dependencies in Cargo.toml, including cli, core,
+  exec, linux-sandbox, tui, login, ollama, and mcp.
+
 • Ran
   └ for d in ansi-escape apply-patch arg0 cli common core exec execpolicy
         file-search linux-sandbox login mcp-client mcp-server mcp-types ollama
@@ -19,6 +26,79 @@ expression: visible_after
 • Explored
   └ Read Cargo.toml
 
+• I’m evaluating how binary size is influenced by various factors. There are
+  many binaries, such as codex and codex-exec, which include dependencies by
+  default, pulling in features like Tokio and hyper. For instance, reqwest
+  includes default features like TLS through rustls. If default features remain
+  enabled, it inflates the size with many additional components. I notice
+  that for musl targets, using vendored builds of OpenSSL could significantly
+  increase binary size. This is quite the intricate web of dependencies!
+
+  Analyzing musl and binary size
+
+  I’m considering the implications of building for musl with static linking.
+  In this case, OpenSSL might come into play through some crates, but reqwest
+  defaults to using rustls, although openssl-sys vendored could increase
+  binary size. It’s interesting to think about whether they’re targeting musl,
+  especially since it seems they might often be building for Mac and Linux with
+  dynamic linking instead.
+
+  I also realize there’s a difference between debug and release builds — release
+  should be smaller due to optimizations, but if they’re defaulting to debug
+  builds, that could lead to much larger binaries.
+
+  Assessing crate impacts on size
+
+  I need to be precise when analyzing binary sizes from various crates. Some
+  crates, like ratatui-image, include heavy features such as libjpeg decoders,
+  which can really bulk things up. Then there are the tree-sitter crates that
+  contain large static grammar tables, adding significant size. The starlark
+  crate and tracing-subscriber also contribute to size increases.
+
+  With static linking per binary being standard in Rust, it leads to multiple
+  copies of the same dependencies unless cdylibs are used. That makes the
+  compile times longer, but using LTO helps reduce bloat somewhat through
+  deduplication.
+
+  Evaluating binary size factors
+
+  Having multiple binaries indeed increases the overall size significantly.
+  I'm considering options like upgrading to "opt-level = 'z'" or using
+  "strip=debuginfo" for reducing size. It's interesting that while the profile
+  only sets symbols for stripping, not debuginfo, this could inflate sizes if
+  retained in release builds.
+
+  The distinction between "symbols" and "debuginfo" is critical; "symbols"
+  keeps debug information which may not align with the goal of minimizing
+  size. I’d like to verify with the Rust documentation, but my network access
+  is restricted.
+
+  Explaining large binary sizes
+
+  I’m analyzing why binaries in this project are so large. The primary reasons
+  include monolithic static linking, where each binary includes the full
+  dependency graph without shared libraries. Heavy dependencies such as reqwest,
+  hyper, and TLS components also contribute significantly to size, along with
+  image decoders and other libraries.
+
+  Using MUSL targets means vendored OpenSSL can drastically increase the
+  size due to static linking. Furthermore, if the release profile keeps debug
+  information due to using "strip = symbols," that can lead to larger binaries
+  as well. It’s a mix of several factors, including panic strategies and
+  platform-specific linking behavior.
+
+  Identifying binary size contributors
+
+  I’m considering why binaries are still large even without static linking. The
+  tracing-subscriber crate potentially adds weight because it includes regex,
+  though it can sometimes use a lighter version. References from files like
+  "core/Cargo.toml" show dependencies like reqwest and tokio, while the tui uses
+  the image crate.
+
+  To present this clearly, I’ll format the final answer with two main sections:
+  "Main Causes" and "Build-Mode Notes." I can also include brief suggestions for
+  reducing size, but I want to stay focused on answering the user's question.
+
 > Here’s what’s driving size in this workspace’s binaries.
 
   Main Causes