1 00:00:00,000 --> 00:00:04,240 We're looking at a major change in how Codex handles multi-agent communication 2 00:00:04,293 --> 00:00:09,760 today, specifically with the upcoming zero-dot-one-forty-dot-zero update. 3 00:00:09,856 --> 00:00:14,720 Maya, if you've been monitoring agent-to-agent chatter in your custom tools, 4 00:00:14,754 --> 00:00:16,240 things are about to go dark. 5 00:00:16,985 --> 00:00:22,085 The team is moving away from sending parent-to-subagent instructions as plaintext. 6 00:00:23,379 --> 00:00:27,179 Wait, those instructions were traveling in plaintext? 7 00:00:27,880 --> 00:00:33,519 So if a parent agent was handing off a task to a subagent, any third-party tool 8 00:00:33,699 --> 00:00:36,039 sitting on that context window could just... 9 00:00:36,179 --> 00:00:37,979 read the entire prompt? 10 00:00:39,000 --> 00:00:40,200 Exactly. 11 00:00:40,300 --> 00:00:45,640 Any standard tool argument or context payload was completely exposed. 12 00:00:45,693 --> 00:00:50,680 If you had a sensitive system prompt or proprietary business logic in those agent 13 00:00:50,735 --> 00:00:53,720 instructions, it was basically an open book. 14 00:00:53,860 --> 00:00:58,600 But in the zero-dot-one-forty update, Codex is routing all of that through a 15 00:00:58,664 --> 00:01:04,360 dedicated field called `InterAgentCommunication.encrypted_content`. 16 00:01:05,420 --> 00:01:08,899 `InterAgentCommunication.encrypted_content`. 17 00:01:09,759 --> 00:01:13,019 Okay, so it's a dedicated ciphertext field. 18 00:01:13,819 --> 00:01:17,880 The runtime encrypts it on one side, passes it through the transport layer, 19 00:01:18,439 --> 00:01:21,979 and then decrypts it internally when the target agent receives it. 20 00:01:22,840 --> 00:01:25,059 But what does this do to our debugging pipelines? 21 00:01:25,719 --> 00:01:29,500 If I'm running middleware to log or intercept agent payloads for tracing, 22 00:01:30,019 --> 00:01:31,979 I'm just going to see garbage data now, right? 23 00:01:33,000 --> 00:01:34,440 Yep, absolute noise. 24 00:01:34,862 --> 00:01:37,966 Your logging proxies will just capture encrypted blobs. 25 00:01:38,179 --> 00:01:43,566 If you rely on sniffing those raw tool arguments to build traces or audit trails, 26 00:01:43,606 --> 00:01:45,726 you're going to have to update your workflows. 27 00:01:45,886 --> 00:01:50,846 You'll need to hook directly into the agent's internal lifecycle hooks or use the 28 00:01:50,917 --> 00:01:56,446 official SDK decryption helpers, rather than just inspecting the JSON packets on the 29 00:01:56,526 --> 00:01:56,926 wire. 30 00:01:57,459 --> 00:02:01,539 That is going to break a lot of custom tooling, but honestly, 31 00:02:01,839 --> 00:02:06,860 thanks to Jellypod to help make this daily show a reality, we can dive deep into 32 00:02:06,899 --> 00:02:09,300 these breaking changes before they hit production. 33 00:02:09,759 --> 00:02:14,420 It's a massive win for security, especially for enterprise deployments where you 34 00:02:14,479 --> 00:02:17,799 cannot have agent prompts leaking to arbitrary tools. 35 00:02:19,000 --> 00:02:19,880 It really is. 36 00:02:19,960 --> 00:02:24,680 And speaking of security, the other half of this update targets the sandboxing 37 00:02:24,733 --> 00:02:25,080 layer. 38 00:02:25,293 --> 00:02:30,520 If you've tried running Codex in a strict Linux sandbox, you've probably hit those 39 00:02:30,600 --> 00:02:33,480 random, silent local tool crashes. 40 00:02:34,105 --> 00:02:39,480 The issue was how Codex handles inter-process communication inside its proxy-routed 41 00:02:39,587 --> 00:02:40,840 seccomp filters. 42 00:02:41,700 --> 00:02:42,500 Ah, let me guess. 43 00:02:42,839 --> 00:02:47,319 The seccomp filter was blocking the system calls needed to spin up local IPC 44 00:02:47,420 --> 00:02:47,859 channels? 45 00:02:49,000 --> 00:02:50,320 Spot on. 46 00:02:50,366 --> 00:02:55,320 Specifically, it was blocking `socketpair` calls with the `AF_UNIX` domain. 47 00:02:55,480 --> 00:03:00,360 The sandbox was so restrictive that when a tool tried to set up a local UNIX socket 48 00:03:00,440 --> 00:03:05,560 pair to talk to its parent process, seccomp instantly killed the thread. 49 00:03:05,740 --> 00:03:11,880 The zero-dot-one-forty release explicitly adds `socketpair(AF_UNIX, 50 00:03:11,940 --> 00:03:17,000 ...)` to the seccomp allowlist, so you keep your strict external network isolation 51 00:03:17,093 --> 00:03:20,120 while letting local IPC actually function. 52 00:03:21,600 --> 00:03:23,500 That explains so much. 53 00:03:24,259 --> 00:03:28,019 I've seen developers tearing their hair out over those silent failures. 54 00:03:28,719 --> 00:03:31,059 But what about Unix socket path limits? 55 00:03:31,579 --> 00:03:35,679 I know Unix has that notorious hundred-and-eight-byte limit for socket paths. 56 00:03:36,179 --> 00:03:40,779 If you have a deeply nested monorepo, you can hit that incredibly fast. 57 00:03:42,000 --> 00:03:48,320 Exactly, `sockaddr_un.sun_path` is strictly limited to one-hundred-and-eight 58 00:03:48,400 --> 00:03:51,280 bytes, null terminator included. 59 00:03:51,440 --> 00:03:53,840 If your workspace path was something like 60 00:03:54,107 --> 00:04:04,400 `/Users/username/projects/company/services/agent/subagent/workspace`, 61 00:04:04,440 --> 00:04:07,280 the socket creation would overflow and crash. 62 00:04:07,440 --> 00:04:11,040 Codex is fixing this by adding an automatic fallback. 63 00:04:11,200 --> 00:04:15,520 If the calculated socket path exceeds one hundred and seven bytes, 64 00:04:15,600 --> 00:04:20,800 it automatically drops the socket file into the system `/tmp` directory instead. 65 00:04:22,740 --> 00:04:24,939 Oh, that's a elegant fallback. 66 00:04:26,519 --> 00:04:31,179 It completely sidesteps the path length restriction without requiring the developer 67 00:04:31,220 --> 00:04:34,119 to reorganize their entire repository structure. 68 00:04:34,899 --> 00:04:36,299 What about Windows users, though? 69 00:04:36,759 --> 00:04:39,979 I know they don't deal with `sockaddr_un` limits in the same way, 70 00:04:40,119 --> 00:04:43,259 but they've had their own nightmare with turn latency lately. 71 00:04:44,000 --> 00:04:45,840 Oh, the fifteen-second hang. 72 00:04:46,832 --> 00:04:49,680 That's been a massive pain point on the community forums. 73 00:04:49,920 --> 00:04:55,120 On Windows, there was this bizarre lag where the system would literally freeze for 74 00:04:55,180 --> 00:04:57,680 fifteen seconds between conversation turns. 75 00:04:57,893 --> 00:05:03,440 It turned out to be a socket cleanup timeout issue in the Windows-specific IPC 76 00:05:03,500 --> 00:05:04,000 wrapper. 77 00:05:05,439 --> 00:05:06,979 Fifteen seconds! 78 00:05:07,379 --> 00:05:11,079 That's an eternity when you're trying to have an interactive debugging session with 79 00:05:11,099 --> 00:05:11,799 an agent. 80 00:05:12,559 --> 00:05:14,479 I'm assuming that's finally resolved? 81 00:05:15,000 --> 00:05:16,200 Completely. 82 00:05:16,232 --> 00:05:20,840 They've refactored the socket closing sequence on Windows to prevent it from waiting 83 00:05:20,893 --> 00:05:24,120 on the lingering TCP close handshake. 84 00:05:24,200 --> 00:05:28,040 Latency is back to near-zero millisecond levels between turns. 85 00:05:29,359 --> 00:05:29,919 Good. 86 00:05:30,620 --> 00:05:35,719 Between the seccomp fixes, the path overflows, and the Windows latency patch, 87 00:05:36,179 --> 00:05:40,759 it feels like this release is really focusing on making the local runtime robust, 88 00:05:41,340 --> 00:05:45,100 even if developers have to rewrite some of their tracing tools for the new encrypted 89 00:05:45,199 --> 00:05:45,699 payloads. 90 00:05:46,000 --> 00:05:46,960 Definitely. 91 00:05:47,024 --> 00:05:52,320 That's our quick look at Codex zero-dot-one-forty-dot-zero. 92 00:05:52,347 --> 00:05:55,040 We'll see how these security changes play out in the wild. 93 00:05:55,890 --> 00:05:56,720 See you next time. 94 00:05:58,219 --> 00:05:58,439 Bye everyone!