1 00:00:00,080 --> 00:00:03,920 So, uh, thanks to Jellypod to help make this daily show a reality. 2 00:00:04,700 --> 00:00:10,360 Yesterday we talked about those really messy CLI 0.142.5 regressions, 3 00:00:10,960 --> 00:00:17,860 but if you upgraded your Codex CLI or Desktop to 0.142.5 this morning and 4 00:00:17,940 --> 00:00:20,140 opened a remote SSH project... 5 00:00:21,520 --> 00:00:23,460 man, you might have had a mini heart attack. 6 00:00:23,980 --> 00:00:25,880 You open the sidebar and it's just... 7 00:00:26,560 --> 00:00:26,980 empty. 8 00:00:27,530 --> 00:00:28,600 "No chats" found. 9 00:00:29,252 --> 00:00:30,732 Oh, no. 10 00:00:30,812 --> 00:00:31,282 That is... 11 00:00:31,332 --> 00:00:36,211 I mean, if you have weeks of context in those threads, that's a nightmare. 12 00:00:36,272 --> 00:00:39,612 Are they actually gone, or is this another path-handling bug? 13 00:00:40,492 --> 00:00:43,432 Thankfully, your thread history is perfectly safe. 14 00:00:43,812 --> 00:00:44,792 It's not deleted. 15 00:00:45,392 --> 00:00:49,472 What's happening under the hood is a pretty aggressive path-normalization change 16 00:00:49,872 --> 00:00:52,942 they introduced in 0.142.5. 17 00:00:53,692 --> 00:00:57,642 Basically, the client now resolves symlinks to their canonical, 18 00:00:57,712 --> 00:01:00,332 absolute paths on the remote server. 19 00:01:00,452 --> 00:01:05,822 So if you're on, say, a Lustre-backed absolute mount or any symlinked directory, 20 00:01:06,312 --> 00:01:11,932 Codex grabs the fully resolved target path and saves the thread's cwd-the current 21 00:01:12,032 --> 00:01:15,532 working directory-using *that* canonical path. 22 00:01:17,026 --> 00:01:17,695 Ah, okay. 23 00:01:17,716 --> 00:01:18,676 Let me see if I get this. 24 00:01:19,366 --> 00:01:23,916 The thread itself gets tagged with the newly resolved absolute path, 25 00:01:24,116 --> 00:01:31,076 like /mnt/lustre/user/project, but what is the sidebar actually looking 26 00:01:31,156 --> 00:01:31,226 at? 27 00:01:31,756 --> 00:01:35,476 Is it still pointing to the original symlink path you used to connect, 28 00:01:35,556 --> 00:01:37,976 like ~/my-project? 29 00:01:38,749 --> 00:01:39,869 Exactly. 30 00:01:39,889 --> 00:01:44,089 The sidebar is still bound to the symlink path you initialized the workspace with. 31 00:01:44,769 --> 00:01:49,829 Because of that exact path mismatch, Codex's UI filter fails to pair them up. 32 00:01:50,489 --> 00:01:55,149 It splits your thread history into a silo, making it look like your conversations 33 00:01:55,209 --> 00:01:58,529 just vanished into thin air, when they're actually just sitting there, 34 00:01:58,989 --> 00:02:03,109 grouped under that newly resolved canonical path in the local database. 35 00:02:04,878 --> 00:02:07,958 It's always the path-normalization bugs, isn't it? 36 00:02:08,458 --> 00:02:10,798 Classic issue #30808 stuff. 37 00:02:11,438 --> 00:02:16,218 So, if the data is still there, how do developers actually get their sidebars to 38 00:02:16,238 --> 00:02:18,568 display those threads again without downgrading? 39 00:02:19,485 --> 00:02:23,405 It's actually a pretty straightforward workaround once you know what's happening. 40 00:02:23,505 --> 00:02:28,345 All you have to do is find the absolute resolved path on your remote server-you can 41 00:02:28,445 --> 00:02:35,185 just run readlink -f on your project directory-and then add that exact canonical 42 00:02:35,245 --> 00:02:38,865 path as a second saved remote project inside Codex. 43 00:02:39,525 --> 00:02:45,005 Once the workspace root matches that resolved path, boom, all your old threads 44 00:02:45,065 --> 00:02:46,965 populate right back into the sidebar. 45 00:02:47,789 --> 00:02:49,418 Oh, that's a lifesaver. 46 00:02:49,958 --> 00:02:55,378 So you don't have to manually edit any SQLite databases or local config files. 47 00:02:55,878 --> 00:02:56,338 You just... 48 00:02:56,578 --> 00:02:58,078 map the real path. 49 00:02:58,938 --> 00:03:04,478 But speaking of regressions, I saw some really nasty reports from people on older 50 00:03:04,558 --> 00:03:09,188 Intel Macs-specifically running macOS 26.3.2. 51 00:03:09,898 --> 00:03:13,498 They were getting flat-out hard crashes, right? 52 00:03:13,538 --> 00:03:14,718 Like a SIGTRAP? 53 00:03:16,165 --> 00:03:19,925 Yeah, the SIGTRAP crash when invoking the built-in exec tool. 54 00:03:20,565 --> 00:03:23,725 That one was tracked in issue #30706. 55 00:03:24,405 --> 00:03:30,925 It turns out it's a V8 heap reservation failure on those specific x86_64 56 00:03:30,945 --> 00:03:35,165 architectures running macOS 26.3.2. 57 00:03:35,865 --> 00:03:40,065 If you're hitting that, the workaround is to hop off the stable release channel and 58 00:03:40,125 --> 00:03:46,415 move to the 0.143.0 alpha branch, where they've backported a fix that relaxes those 59 00:03:46,445 --> 00:03:49,125 memory constraints on initialization. 60 00:03:49,860 --> 00:03:49,861 Huh. 61 00:03:50,010 --> 00:03:51,710 Good to know they've got an alpha fix. 62 00:03:52,430 --> 00:03:54,330 But what about the api side? 63 00:03:54,790 --> 00:03:59,890 Because I've been seeing some weird chatter on Discord about OpenAI quota tracking. 64 00:04:00,490 --> 00:04:04,259 People are complaining that their ChatGPT Plus quotas are just... 65 00:04:04,340 --> 00:04:05,290 evaporating. 66 00:04:05,930 --> 00:04:11,160 Like, jumping from seventy percent used to one hundred percent in under six minutes 67 00:04:11,570 --> 00:04:13,610 without them running massive batch jobs. 68 00:04:14,515 --> 00:04:15,235 Yes! 69 00:04:15,315 --> 00:04:21,394 That is issue #30918, and it's a massive headache for anyone running automated 70 00:04:21,495 --> 00:04:22,655 pipelines. 71 00:04:22,685 --> 00:04:26,955 There's a regression in the prompt-caching logic that causes the client to send 72 00:04:27,015 --> 00:04:32,535 redundant system prompt tokens on every single turn instead of utilizing the cache. 73 00:04:33,395 --> 00:04:37,295 If you think you're getting hit by this, you can actually verify it locally. 74 00:04:38,055 --> 00:04:42,815 Go into your project directory and inspect the local JSONL session logs. 75 00:04:43,475 --> 00:04:48,535 Look at the prompt token usage metrics in those entries-if you see the token count 76 00:04:48,635 --> 00:04:52,245 scaling linearly with every message instead of staying flat, 77 00:04:52,915 --> 00:04:55,835 you're experiencing #30918. 78 00:04:57,324 --> 00:05:01,374 Right, because it's re-sending the whole history every time. 79 00:05:01,414 --> 00:05:04,114 Well, at least the JSONL logs don't lie. 80 00:05:04,174 --> 00:05:06,874 That's a lot of useful debugging info for one morning. 81 00:05:07,992 --> 00:05:08,552 Definitely. 82 00:05:09,012 --> 00:05:11,072 Keep an eye on those paths and those logs. 83 00:05:11,592 --> 00:05:12,812 Talk to you tomorrow, Maya. 84 00:05:14,592 --> 00:05:15,382 Yep, talk then.