Claude Code binary silently disables transparent huge pages (THP)

Hello! Please revive this issue. Many compute/memory-intensive workloads that are run inside of Claude Code are severely degraded due to the binary's own THP flags being inherited by shell calls via fork/exec. Like the OP mentioned, this is completely silent and even explicit madvise calls from the child proc are ignored. `` systemd THP=1 └─ tmux server (new-session) THP=1 └─ -zsh (your pane shell) THP=1 └─ claude --resume THP=0 ← disabled here └─ this bash shell THP=0 ← inherits from claude ` There is an explicit call to prctl(PR_SET_THP_DISABLED, 1) somewhere on Claude Code's start-up path. My current workaround is to nudge Claude into wrapping all shell calls with a wrapper to re-enable THP: `c #include <sys/prctl.h> #include <unistd.h> int main(int argc, char **argv) { prctl(PR_SET_THP_DISABLE, 0, 0, 0, 0); execvp(argv[1], &argv[1]); return 127; } ` CLAUDE.md ` ## Transparent Huge Pages (THP) We never want a shell session running with THP *explicitly* disabled. THP should be governed only by the OS default or by a process disabling it for itself — never by an inherited disable flag. The claude binary disables THP for itself, and that flag is inherited by every command it spawns, which pessimizes compute-heavy work. Therefore wrap all shell invocations with ~/.local/bin/thp-madvise, which clears the inherited disable flag (restoring the OS default) before exec'ing the real command. For example, run ~/.local/bin/thp-madvise my-command rather than my-command. ` Gemini CLI does not have this behavior. THP for agy can be explicitly disabled with TCMALLOC_TESTONLY_DISABLE_THP_ON_INIT=1` and when it is set, a very prominent warning is shown in the CLI about the potential for degraded performance.

_Originally posted by @y4n9squared in #53471_