1
00:00:00,000 --> 00:00:04,320
So if you're on Windows and Codex
sandboxed commands have been dying before they

2
00:00:04,368 --> 00:00:06,400
even start, this one's for you.

3
00:00:06,560 --> 00:00:10,640
And thanks to Jellypod for helping make
this daily show a reality.

4
00:00:10,832 --> 00:00:17,200
Last time we covered 0.162.1 and the Linux
sandbox fixes in

5
00:00:17,360 --> 00:00:19,600
0.162.0.

6
00:00:19,720 --> 00:00:24,480
Today is the Windows side of that same
release line, and it's a case where the fix

7
00:00:24,560 --> 00:00:26,960
exists but stable users can't get it.

8
00:00:27,280 --> 00:00:27,480
Right.

9
00:00:27,640 --> 00:00:32,140
The symptom is that sandboxed execution
fails completely before running a single

10
00:00:32,220 --> 00:00:32,560
command.

11
00:00:33,100 --> 00:00:39,980
Codex desktop, package 26.1002.7124.0 for
example, and CLI

12
00:00:40,380 --> 00:00:44,600
0.162.0 and 0.162.1 all show it.

13
00:00:45,120 --> 00:00:50,120
The error says helper_unknown_error: setup
refresh had errors.

14
00:00:50,660 --> 00:00:56,600
Dig into the logs and the underlying cause
is os error 32, a sharing violation.

15
00:00:57,080 --> 00:01:01,300
That's Windows saying the process cannot
access the file because it is being used by

16
00:01:01,340 --> 00:01:02,140
another process.

17
00:01:02,458 --> 00:01:09,018
The mechanism lives in the Windows sandbox
crate, in a file called acl.rs.

18
00:01:09,138 --> 00:01:13,818
The setup helper runs a runtime read and
execute validation step.

19
00:01:13,944 --> 00:01:20,778
Before PR #51822, it opened every root
only ACL target

20
00:01:20,826 --> 00:01:27,098
with the same options: access mode
MAXIMUM_ALLOWED, share mode

21
00:01:27,210 --> 00:01:31,498
read, write and delete, and the backup
semantics flag.

22
00:01:31,645 --> 00:01:33,658
Files and directories alike.

23
00:01:33,907 --> 00:01:37,327
And that's the problem, because by the
time sandbox setup runs,

24
00:01:37,607 --> 00:01:40,947
Codex has already started its own
background runtime helpers.

25
00:01:41,547 --> 00:01:47,967
The reports name node_repl.exe, node.exe,
and codex computer use

26
00:01:48,047 --> 00:01:53,907
swift.exe, living under your AppData Local
OpenAI Codex runtimes folder,

27
00:01:54,387 --> 00:01:57,627
in cua_node, then a hash, then bin.

28
00:01:58,387 --> 00:02:02,647
Those processes hold their executables
open with only read sharing.

29
00:02:03,167 --> 00:02:08,387
Windows won't let you open an actively
executing image with MAXIMUM_ALLOWED in that

30
00:02:08,427 --> 00:02:09,047
situation.

31
00:02:09,627 --> 00:02:14,027
One of the issue threads quotes it
directly: Windows does not allow modifying the

32
00:02:14,067 --> 00:02:17,547
security descriptor of a file that is
currently mapped as an image.

33
00:02:18,107 --> 00:02:22,147
So Codex's own helpers block Codex's own
sandbox setup.

34
00:02:22,458 --> 00:02:29,338
PR #51822 is titled Avoid sharing
violations when repairing Windows runtime

35
00:02:29,478 --> 00:02:30,138
ACLs.

36
00:02:30,298 --> 00:02:31,898
The change is narrow.

37
00:02:32,138 --> 00:02:37,658
MAXIMUM_ALLOWED is now used only on
directories, behind an is_dir guard,

38
00:02:37,698 --> 00:02:42,138
because directories are the ones that need
it to suppress child ACL inheritance.

39
00:02:42,318 --> 00:02:48,538
For files, it requests just READ_CONTROL
and WRITE_DAC, and only when an ACL update

40
00:02:48,591 --> 00:02:49,738
is actually necessary.

41
00:02:49,978 --> 00:02:54,938
So a running executable never gets the
broad open that triggers the violation.

42
00:02:55,218 --> 00:02:56,118
Now the trap.

43
00:02:56,538 --> 00:03:00,998
That PR merged into main on October 7 at
20:47 UTC.

44
00:03:01,798 --> 00:03:07,338
The 0.162.0 stable line had branched from
main roughly 20 hours earlier,

45
00:03:07,738 --> 00:03:10,358
October 7 at 00:51 UTC.

46
00:03:11,017 --> 00:03:15,738
So 0.162.0, tagged October 8, doesn't
contain the fix.

47
00:03:16,558 --> 00:03:23,278
Then 0.162.1 was tagged October 9, cut
from the release 0.162 maintenance branch,

48
00:03:23,838 --> 00:03:27,018
and it did not backport #51822.

49
00:03:27,458 --> 00:03:31,518
Its two fixes were the multiline TUI crash
and the background server feature

50
00:03:31,618 --> 00:03:32,778
settings startup failure.

51
00:03:33,278 --> 00:03:34,338
Neither touches this.

52
00:03:34,667 --> 00:03:39,627
The practical result: as of the research
we have, no stable release includes the

53
00:03:39,747 --> 00:03:40,267
fix.

54
00:03:40,400 --> 00:03:42,747
It's only in prerelease tags.

55
00:03:43,147 --> 00:03:48,187
0.162.0 alpha 19 and alpha 20, and

56
00:03:48,347 --> 00:03:55,227
0.163.0 alpha 1 through alpha 5, with
alpha 5 released October

57
00:03:55,307 --> 00:03:55,707
10.

58
00:03:55,851 --> 00:04:00,587
That's from the issue tracker, so check
the releases page for anything newer before

59
00:04:00,627 --> 00:04:01,227
you act.

60
00:04:01,490 --> 00:04:05,430
Here's how to tell whether your build has
the fix, because version numbers alone

61
00:04:05,730 --> 00:04:06,250
won't do it.

62
00:04:06,890 --> 00:04:12,170
Open the sandbox log, at tilde slash dot
codex slash dot sandbox,

63
00:04:12,570 --> 00:04:15,050
a file named sandbox, then the date, dot
log.

64
00:04:15,890 --> 00:04:19,310
PR #51822 renamed the error string.

65
00:04:19,710 --> 00:04:23,910
Builds before the fix log: open ACL target
for root only update,

66
00:04:24,130 --> 00:04:25,110
with a colon after it.

67
00:04:25,790 --> 00:04:29,770
Builds with the fix log: open ACL target
for root only update,

68
00:04:29,870 --> 00:04:32,730
followed by MAXIMUM_ALLOWED in
parentheses.

69
00:04:33,549 --> 00:04:38,310
If you don't see that parenthesized
suffix, your build lacks #51822,

70
00:04:38,750 --> 00:04:42,690
whether it says 0.162.0 or 0.162.1.

71
00:04:43,042 --> 00:04:46,482
Now workarounds, in order of how much they
cost you.

72
00:04:46,615 --> 00:04:51,762
First, switch from sandboxed mode, the ask
for approval setup,

73
00:04:51,789 --> 00:04:53,682
to Full Access in the app.

74
00:04:53,762 --> 00:04:59,282
Full Access skips sandbox provisioning, so
the setup helper never runs and commands

75
00:04:59,335 --> 00:04:59,922
go through.

76
00:05:00,082 --> 00:05:02,082
But understand what you're trading.

77
00:05:02,222 --> 00:05:07,922
You've turned off sandbox isolation, so
only do that in a repo and on a machine

78
00:05:07,949 --> 00:05:09,122
where you're comfortable with it.

79
00:05:09,345 --> 00:05:13,184
Second, if you need the sandbox, run a
prerelease that has the fix.

80
00:05:13,725 --> 00:05:19,245
Install it globally with npm, the package
is openai slash codex at the alpha tag,

81
00:05:19,865 --> 00:05:24,105
or pin 0.163.0 alpha 5 specifically.

82
00:05:24,785 --> 00:05:28,705
One thing that does not work: killing
node_repl.exe.

83
00:05:29,285 --> 00:05:33,745
Codex respawns those processes as soon as
you run a task, so you'll clear the lock

84
00:05:33,785 --> 00:05:35,985
for a moment and it will come right back.

85
00:05:36,292 --> 00:05:38,532
And a caveat on the prerelease path.

86
00:05:38,745 --> 00:05:44,292
If you land on 0.163.0 alpha 1, there's
issue

87
00:05:44,532 --> 00:05:46,612
#52313.

88
00:05:46,905 --> 00:05:53,812
PR #52195 added per content source
attribution, which sends

89
00:05:53,892 --> 00:05:58,052
content_item_metadata in request payloads.

90
00:05:58,212 --> 00:06:04,436
With GPT 6.1 Sol, where use_responses_lite
is true, the Responses Lite backend

91
00:06:04,468 --> 00:06:10,825
rejects that parameter with an HTTP 400
invalid_request_error.

92
00:06:10,879 --> 00:06:16,239
The reported workaround is to pass the
disable flag for the content_item_kinds

93
00:06:16,532 --> 00:06:17,092
feature.

94
00:06:17,172 --> 00:06:20,372
Alphas are alphas, so test before you roll
one out to a team.

95
00:06:20,655 --> 00:06:25,275
A couple of smaller things from 0.162.0
worth knowing while you're in there.

96
00:06:25,715 --> 00:06:30,375
In Code Mode, there are now JavaScript
helpers for streaming promise results as they

97
00:06:30,415 --> 00:06:33,895
settle, so you aren't waiting on the
slowest call before you see the rest.

98
00:06:34,355 --> 00:06:40,015
There's also opt in ranked tool search in
Code Mode, from PRs #51126 and

99
00:06:40,055 --> 00:06:41,655
#51209.

100
00:06:41,958 --> 00:06:48,678
And for custom model providers, PR #50459
adds capability

101
00:06:48,750 --> 00:06:50,278
overrides in config.

102
00:06:50,418 --> 00:06:55,958
You can now configure live web access and
remote context compaction for custom

103
00:06:56,030 --> 00:07:00,358
Responses compatible endpoints, rather
than having those assumed off.

104
00:07:00,715 --> 00:07:05,515
So the takeaway: if your Windows sandbox
is failing, check the log string before

105
00:07:05,555 --> 00:07:06,335
blaming your setup.

106
00:07:06,815 --> 00:07:09,955
No parenthesized MAXIMUM_ALLOWED means no
fix.

107
00:07:10,515 --> 00:07:14,795
Use Full Access if you must, move to an
alpha if you need isolation,

108
00:07:15,335 --> 00:07:21,455
and watch for a 0.162.2 or a 0.163 stable
that actually carries

109
00:07:21,655 --> 00:07:23,135
#51822.