Repository navigation
Regression: sudo #5413
Description
Description
In wheel group, in v0.8.65 on yolo my codewhale could have used sudo fine. in v0.9.7 it apparently can't. I attach screenshots.
Steps to reproduce
in 0.9.7 (dev) operate max Full Access files: full disk
ask it: quick check, can you use sudo? or ask it to do: sudo -n true 2>&1; echo "exit=$?"
Expected behavior
I would generally expect some version of full privileges on systems with user in wheel group. It is useful for example in system server administration.
Actual behavior
v0.8.65 command returns true. Codewhale can do everything if I run it with privileged user.
v0.9.7 one says:
run done · sudo -n true 2>&1; echo "exit=$?"
output: sudo: The "no new privileges" flag is set, which prevents sudo from running as root.
sudo: If sudo is running in a container, you may need to adjust the container configuration to disable the flag.
exit=1
Impact
A lot, actually. Bootstrapping a server, data science server computations or developing/maintaining dev-ops on wheel is quite fast. One can just ssh inside set up codewhale there and leave it to tasks.
Environment
OS: Arch Linux
codewhale version: 0.9.7 (dev)
Install method: cargo install
Model/provider: deepseek-v4-pro / DeepSeek
Terminal app: kitty, ssh
Shell: zsh
Linux fix, but needs other fix on other distros, proposed by codewhale(not verified):
process_hardening.rs
let result = unsafe { libc::prctl(libc::PR_SET_NO_NEW_PRIVS, 1i64, 0i64, 0i64, 0i64) };
// change to:
if std::env::var_os("CODEWHALE_ALLOW_SUDO").is_none() {
let result = unsafe { libc::prctl(libc::PR_SET_NO_NEW_PRIVS, 1i64, 0i64, 0i64, 0i64) };
// ... existing warn/log handling ...
}
Philosophy
Now, the question is, do we want to have privileged users to explicitly spawn it sand-boxed, or explicitly spawn it on the same privilege level.
Logs, screenshots, or recordings
v0.8.65:
v0.9.7
Activity
github-actions commentedon Aug 16, 2026
Thanks @M-Maciej for the report.
This issue is staying open for maintainer triage. CodeWhale gets better because people bring us real edge cases from real machines, providers, regions, and workflows.
If you can add a reproduction, logs, version output, screenshots, or the provider/model involved, that makes it much easier for us to verify and harvest the fix. Maintainers may comment
/lgtmito mark recurring issue reporters as approved so this intake note is skipped next time.Merge pull request #5425 from Hmbown/work/v098-integration-20260815
Hmbown commentedon Aug 16, 2026
Root-caused and fixed — thank you @M-Maciej, your analysis was exactly right down to the line.
Cause. Startup hardening (#2183, landed after 0.8.65) calls
prctl(PR_SET_NO_NEW_PRIVS, 1)on the TUI process. That flag is irreversible andinherited by every child, so
sudo,su, and setuid/fscaps helpers fail for thewhole process tree — which is why your
sudo -n truecheck returnssudo: The "no new privileges" flag is set.Fix in v0.9.8.
CODEWHALE_NO_NEW_PRIVSwith any falsey value(
0,false,no,off,disabled, or empty) skips exactly that one flag atstartup; everything else (including typos) keeps the hardened posture. The other
two measures (no ptrace via
PR_SET_DUMPABLE=0, no core dumps viaRLIMIT_CORE=0) are never skipped:CODEWHALE_NO_NEW_PRIVS=0 codewhale # sudo works again for the treeIt's an env var rather than a config key because hardening runs before config is
parsed — the same point your fix sketch targeted.
On your philosophy question — we landed where you did: the default keeps the
defense-in-depth posture for everyone, and the explicit opt-out is the user
saying "this process tree is allowed to escalate." That preserves the protection
for the 99% case (a model must not be able to setuid its way out) without
breaking the administered-server workflow you described. If a config-file form
would help your setup, say so and we'll wire one for 0.9.9.
fix(tui): full access means it — skip PR_SET_NO_NEW_PRIVS under dange…