1
00:00:00,159 --> 00:00:05,440
Imagine you are sitting on your Mac,
sending code execution tasks over a WebSocket

2
00:00:05,500 --> 00:00:07,059
to a remote Linux executor.

3
00:00:07,819 --> 00:00:12,099
You think your sensitive files are
completely locked down behind deny read rules.

4
00:00:12,880 --> 00:00:17,840
But, uh, what if the sandbox was actually
looking at your local Mac file paths

5
00:00:17,920 --> 00:00:20,680
instead of the Linux box where the code is
actually running?

6
00:00:21,680 --> 00:00:25,459
Big thanks to Jellypod for sponsoring
today's episode of the daily show.

7
00:00:26,079 --> 00:00:31,579
Today, we are digging into Codex zero
point one fifty-one point zero and a really

8
00:00:31,619 --> 00:00:34,340
fascinating set of security and sandbox
updates.

9
00:00:34,796 --> 00:00:39,756
Yeah, that, that local versus remote path
mix up is such a wild bug.

10
00:00:40,456 --> 00:00:44,677
In open source release notes for Codex
zero point one fifty-one point zero,

11
00:00:45,236 --> 00:00:49,837
they highlight how remote sandbox
enforcement was upgraded to use the executor's

12
00:00:49,956 --> 00:00:53,296
actual home directory, operating system,
and path conventions.

13
00:00:53,917 --> 00:00:58,837
Before this fix, if you were running the
Codex CLI on macOS or Windows against a

14
00:00:58,896 --> 00:01:04,976
remote Linux target, the client was
evaluating path rules like deny read using local

15
00:01:05,056 --> 00:01:05,996
path semantics.

16
00:01:06,576 --> 00:01:11,757
So, um, if you told it to block access to
relative paths like tilde slash dot ssh,

17
00:01:12,257 --> 00:01:15,457
your local machine was trying to resolve
that before sending it over.

18
00:01:16,393 --> 00:01:20,352
Wait, so if your local client is on
Windows using backslashes,

19
00:01:20,872 --> 00:01:26,992
or on macOS, it might calculate a path
boundary that means absolutely nothing to a

20
00:01:27,072 --> 00:01:30,812
remote Linux environment using standard
POSIX slashes?

21
00:01:31,215 --> 00:01:32,054
Exactly!

22
00:01:32,574 --> 00:01:36,154
The remote Linux worker has a completely
different home directory,

23
00:01:36,594 --> 00:01:40,594
like slash home slash deploy, and uses
forward slashes.

24
00:01:41,215 --> 00:01:46,954
If the client evaluates the rule against C
backslash Users or your Mac home folder,

25
00:01:47,514 --> 00:01:51,334
the remote executor doesn't realize those
Linux paths should be blocked.

26
00:01:51,994 --> 00:01:56,214
The deny read sandbox filter basically
misses the target entirely.

27
00:01:56,542 --> 00:01:59,502
That is a massive cross platform sandbox
flaw.

28
00:01:59,715 --> 00:02:05,262
So how did pull requests 41204, 41207, and

29
00:02:05,422 --> 00:02:08,942
41209 actually fix this under the hood?

30
00:02:09,337 --> 00:02:14,517
They shifted path resolution entirely to
the remote executor's turn environment.

31
00:02:15,217 --> 00:02:20,497
Now, environment variables like CODEX
EXECUTOR HOME, the native path separators,

32
00:02:20,857 --> 00:02:25,317
and actual operating system conventions
are propagated across the boundary.

33
00:02:25,997 --> 00:02:32,837
So when a rule says deny read for tilde
slash dot ssh, it evaluates directly against

34
00:02:32,897 --> 00:02:38,937
slash home slash deploy slash dot ssh on
the remote machine using Linux path rules,

35
00:02:39,337 --> 00:02:42,117
regardless of what OS the CLI client is
running on.

36
00:02:42,557 --> 00:02:44,157
That makes so much sense.

37
00:02:44,777 --> 00:02:48,817
If you are a developer setting up remote
WebSocket executors right now,

38
00:02:49,458 --> 00:02:51,178
what is the best way to test this?

39
00:02:51,838 --> 00:02:57,378
You will definitely want to open up your
repository level dot codex slash config dot

40
00:02:57,557 --> 00:03:01,237
toml file and define explicit deny read
boundaries.

41
00:03:01,917 --> 00:03:06,817
Then run a test turn using a client on
Windows or Mac connected to your Linux build

42
00:03:06,878 --> 00:03:12,237
box, and verify that attempting to read
outside the sandbox throws an immediate

43
00:03:12,317 --> 00:03:15,857
permission denied error directly from the
executor environment.

44
00:03:16,296 --> 00:03:23,056
Speaking of fixing subtle bugs across turn
boundaries, pull requests 41195 and

45
00:03:23,316 --> 00:03:28,837
41206 tackle something that used to drive
me crazy when working with multi model

46
00:03:28,896 --> 00:03:29,297
setups.

47
00:03:29,936 --> 00:03:32,276
Have you ever been in the middle of an
interactive session,

48
00:03:32,776 --> 00:03:37,376
switched models mid stream, or had the
system fall back to an Ultra reasoning model,

49
00:03:37,896 --> 00:03:40,796
and suddenly half your tools just
vanished?

50
00:03:41,805 --> 00:03:46,585
Oh yeah, or worse, the reasoning
parameters get corrupted because the system assumes

51
00:03:46,625 --> 00:03:51,925
the new model shares the exact same tool
schema and reasoning effort budget as the

52
00:03:52,005 --> 00:03:52,364
old one.

53
00:03:52,816 --> 00:03:53,256
Right!

54
00:03:53,816 --> 00:03:58,676
That was happening because the old tool
router held onto a static plan created at

55
00:03:58,716 --> 00:03:59,996
the beginning of the session.

56
00:04:00,616 --> 00:04:05,856
In zero point one fifty-one point zero,
the ToolRouter got a complete refactor.

57
00:04:06,396 --> 00:04:11,616
It now calculates model specific tool
plans dynamically on every single turn.

58
00:04:12,076 --> 00:04:17,176
Ah, so if you start with one model and
then hit a fallback or explicitly swap

59
00:04:17,216 --> 00:04:22,736
models, the updated ToolRouter
re-evaluates tool availability and reasoning effort

60
00:04:22,757 --> 00:04:25,116
specifically for the target model.

61
00:04:25,176 --> 00:04:29,456
Your specialized tools stay accessible,
and the reasoning fallback remains model

62
00:04:29,576 --> 00:04:31,056
aware throughout the entire turn.

63
00:04:31,265 --> 00:04:31,984
Exactly.

64
00:04:32,564 --> 00:04:38,844
And while we are talking about turn
execution, pull request 41196 brings a huge

65
00:04:38,904 --> 00:04:43,524
improvement for anyone building custom
integrations on top of the app server or

66
00:04:43,604 --> 00:04:45,224
Model Context Protocol servers.

67
00:04:45,904 --> 00:04:51,004
Previously, if an MCP server hit an error,
the app server would often flatten that

68
00:04:51,045 --> 00:04:53,924
structured error into a plain text string
exception.

69
00:04:54,747 --> 00:04:59,407
Which makes programmatic error handling
practically impossible because your client

70
00:04:59,507 --> 00:05:06,008
just gets an unparseable blob of text
instead of the original JSON RPC error code

71
00:05:06,048 --> 00:05:06,967
and structured data.

72
00:05:07,382 --> 00:05:08,242
Precisely.

73
00:05:08,943 --> 00:05:14,002
Now, structured MCP tool and resource
errors are fully preserved in app server

74
00:05:14,043 --> 00:05:15,162
responses.

75
00:05:15,242 --> 00:05:19,662
You get the exact structured error
response back, so your client extensions can

76
00:05:19,742 --> 00:05:24,202
inspect, log, or recover from specific
tool failures cleanly.

77
00:05:24,500 --> 00:05:26,820
That is a massive win for reliability.

78
00:05:27,060 --> 00:05:32,740
If you are running mixed operating system
remote executor setups or building custom

79
00:05:32,940 --> 00:05:39,860
MCP extensions, definitely update to Codex
zero point one fifty-one point zero or

80
00:05:39,900 --> 00:05:44,820
the latest alpha releases, and double
check your path rules and error handlers.

81
00:05:44,960 --> 00:05:47,500
Alright, that is it for today.

82
00:05:47,572 --> 00:05:49,540
Good chatting with you, talk soon!