1 00:00:00,000 --> 00:00:06,560 So, so, so get this-- v0.145.0 drops, we get our context-saving 2 00:00:06,640 --> 00:00:11,680 tools, and then literally forty-eight hours later, the team has to rush out 3 00:00:12,000 --> 00:00:15,200 v0.145.2. 4 00:00:15,413 --> 00:00:18,240 It-it-it wasn't even a planned release. 5 00:00:18,352 --> 00:00:25,200 They had a massive, massive regression with the --sandbox flag where child processes 6 00:00:25,232 --> 00:00:26,320 were just... 7 00:00:26,370 --> 00:00:26,880 hanging. 8 00:00:27,008 --> 00:00:28,640 Like, indefinitely. 9 00:00:28,768 --> 00:00:34,400 Just sitting there eating up resources because of unclosed stdin file descriptors. 10 00:00:35,976 --> 00:00:38,736 Oh, the classic zombie process trap! 11 00:00:39,196 --> 00:00:43,217 I-I actually ran into this exact thing when I was testing the release branch. 12 00:00:43,837 --> 00:00:47,236 I had this simple background test suite running inside the sandbox, 13 00:00:47,356 --> 00:00:47,516 right? 14 00:00:48,076 --> 00:00:53,816 Codex crashed-- just went totally silent-- but it kept port 8080 bound. 15 00:00:53,976 --> 00:00:58,376 I spent like, I don't know, forty-five minutes scratching my head wondering why I 16 00:00:58,436 --> 00:01:02,756 was getting phantom server errors on a port that was supposed to be completely free. 17 00:01:03,304 --> 00:01:04,504 Port 8080. 18 00:01:05,024 --> 00:01:09,924 Yeah, because the parent process died but the child process didn't get the memo. 19 00:01:09,984 --> 00:01:14,024 It's because of how they were handling the redirection of standard output. 20 00:01:14,104 --> 00:01:17,345 It was creating this local terminal loop that just... 21 00:01:17,524 --> 00:01:19,484 swallowed error codes. 22 00:01:19,565 --> 00:01:22,684 You'd think the terminal would throw a fit, but it just went quiet. 23 00:01:23,107 --> 00:01:23,587 Right! 24 00:01:23,727 --> 00:01:29,128 It just hangs there, pretending everything is totally fine while your terminal is 25 00:01:29,168 --> 00:01:30,347 essentially choked. 26 00:01:30,968 --> 00:01:34,067 So, how did they actually patch it in 145.2? 27 00:01:34,548 --> 00:01:36,647 Is there a new config we have to throw at it? 28 00:01:37,000 --> 00:01:39,000 They introduced a new environment variable. 29 00:01:39,133 --> 00:01:42,760 It's called-- let me make sure I get the exact spelling-- 30 00:01:42,840 --> 00:01:48,200 CODEX_STRICT_SANDBOX_STDOUTS=1. 31 00:01:48,440 --> 00:01:55,320 If you set that to one, it forces a complete process-tree termination the absolute 32 00:01:55,400 --> 00:01:58,280 second the parent CLI thread terminates. 33 00:01:58,467 --> 00:02:02,440 No more dangling pipes, no more phantom port bindings. 34 00:02:02,697 --> 00:02:04,137 Oh, thank goodness. 35 00:02:04,557 --> 00:02:08,977 That is going to save so many CI/CD pipelines from just spinning until they hit 36 00:02:08,997 --> 00:02:11,258 their fifteen-minute timeout limits. 37 00:02:11,317 --> 00:02:15,298 It-it honestly feels like they had to hack a quick safety valve into the Rust 38 00:02:15,418 --> 00:02:19,657 runtime because the OS-level pipe cleanup wasn't triggering fast enough. 39 00:02:20,117 --> 00:02:21,597 That's exactly what it is. 40 00:02:22,138 --> 00:02:26,657 The Rust parent thread was exiting, but because the file descriptors for standard 41 00:02:26,737 --> 00:02:31,458 input and output were still technically open, the operating system kernel kept the 42 00:02:31,497 --> 00:02:36,317 child process alive, waiting for data that was never, ever going to come. 43 00:02:36,674 --> 00:02:40,234 Which actually leads right into the other big headache with this patch. 44 00:02:40,694 --> 00:02:44,635 If you're running this in an enterprise environment, those child processes are 45 00:02:44,894 --> 00:02:49,054 constantly trying to talk to the local network or dial home for updates, 46 00:02:49,114 --> 00:02:50,835 and enterprise firewalls are... 47 00:02:51,354 --> 00:02:53,314 well, they're having a field day with it. 48 00:02:53,715 --> 00:02:58,654 They're triggering these false positive "Guardian" safety violations left and right. 49 00:02:59,000 --> 00:03:00,040 Mm, yeah. 50 00:03:00,180 --> 00:03:03,240 The deep packet inspection, DPI. 51 00:03:03,360 --> 00:03:08,040 The firewalls see traffic leaving a developer's machine that looks like encrypted 52 00:03:08,120 --> 00:03:13,240 code snippets or trace logs, and they assume it's data exfiltration. 53 00:03:13,320 --> 00:03:18,600 So, v0.145.2 adds this brand-new CLI flag: 54 00:03:18,973 --> 00:03:21,640 --scrub-secrets-level. 55 00:03:21,965 --> 00:03:24,105 Wait, so what are the levels? 56 00:03:24,444 --> 00:03:28,364 Is it just an on-off switch or do we get some actual granularity? 57 00:03:28,750 --> 00:03:30,270 It's got three distinct levels. 58 00:03:30,370 --> 00:03:35,630 You've got "basic," which just sanitizes standard environment variables and things 59 00:03:35,678 --> 00:03:37,550 like obvious AWS keys. 60 00:03:37,694 --> 00:03:43,790 Then you've got "strict," which does a heavy regex sweep for PII-- like emails and 61 00:03:43,897 --> 00:03:47,950 IP addresses-- before anything hits local disk or a proxy. 62 00:03:48,130 --> 00:03:49,870 And then there's "total." 63 00:03:50,294 --> 00:03:50,914 Let me guess... 64 00:03:51,334 --> 00:03:54,954 "total" just turns the logs into absolute mush? 65 00:03:56,094 --> 00:03:56,735 Pretty much. 66 00:03:57,214 --> 00:04:00,914 It strips out almost everything except the barest error codes. 67 00:04:01,694 --> 00:04:06,634 But, if you're behind a crazy strict firewall, that's what you need to keep the DPI 68 00:04:06,675 --> 00:04:07,914 from killing your connections. 69 00:04:08,634 --> 00:04:12,975 But the really clever fix they added is the local proxy bypass tool. 70 00:04:13,715 --> 00:04:19,614 You can configure a .codex/trusted_hosts.json file now. 71 00:04:19,988 --> 00:04:21,208 Oh, interesting. 72 00:04:21,928 --> 00:04:26,967 So instead of completely disabling the local Rust-based command firewall, 73 00:04:27,387 --> 00:04:32,247 which is a massive security risk, you can just whitelist your internal company 74 00:04:32,387 --> 00:04:32,848 proxy? 75 00:04:33,208 --> 00:04:34,208 Exactly. 76 00:04:34,278 --> 00:04:40,808 You specify the exact domain or IP of your proxy in trusted_hosts.json. 77 00:04:40,948 --> 00:04:46,088 The local CLI firewall sees that, says "okay, you're allowed to talk to this 78 00:04:46,141 --> 00:04:50,488 specific gateway," but it still blocks any rogue external requests. 79 00:04:50,621 --> 00:04:55,208 It's the middle ground that enterprise security teams have been screaming for since 80 00:04:55,228 --> 00:04:57,528 the v0.14 series launched. 81 00:04:57,941 --> 00:05:03,661 So if I'm setting this up on a clean developer VM today, the play is: combine the 82 00:05:03,781 --> 00:05:09,181 headless token caching we got in v0.145.0 with this new 83 00:05:09,241 --> 00:05:15,401 CODEX_STRICT_SANDBOX_STDOUTS=1 environment variable, and then drop a 84 00:05:15,521 --> 00:05:18,581 trusted_hosts.json in the root config directory. 85 00:05:19,181 --> 00:05:23,481 That should give you a completely isolated, silent, and compliant setup. 86 00:05:23,833 --> 00:05:24,793 That's the formula. 87 00:05:24,980 --> 00:05:30,313 It's a bit of a manual setup for now, but it completely stabilizes the runtime. 88 00:05:30,526 --> 00:05:34,953 No more zombie ports, no more angry calls from the NetSec team. 89 00:05:35,073 --> 00:05:39,353 Alright, I think that's the quick take on 145.2. 90 00:05:39,513 --> 00:05:44,153 Let's go get some coffee and actually update our test rigs before they break again. 91 00:05:46,066 --> 00:05:49,087 Yeah, before my port 8080 gets haunted again. 92 00:05:49,506 --> 00:05:50,506 Sounds good, let's do it.