1
00:00:00,620 --> 00:00:05,060
So, if you've been working on your local
automation setup this week and suddenly hit

2
00:00:05,120 --> 00:00:11,100
an MCP error -32602, you are definitely
not alone.

3
00:00:11,160 --> 00:00:17,080
It's this super frustrating issue where
the logs start screaming that sandboxCwd

4
00:00:17,140 --> 00:00:19,580
must use the file URI scheme.

5
00:00:19,660 --> 00:00:24,900
Maya, I spent about three hours yesterday
digging into slash_input.rs because of

6
00:00:24,940 --> 00:00:26,700
this exact validation failure.

7
00:00:27,450 --> 00:00:30,540
Oh, wait, slash_input.rs?

8
00:00:31,220 --> 00:00:35,540
So this is actually failing deep in the
input parsing before it even hits the

9
00:00:35,580 --> 00:00:36,320
sandbox runner?

10
00:00:37,293 --> 00:00:37,873
Exactly.

11
00:00:38,393 --> 00:00:43,593
What's happening is that Codex Desktop has
this incredibly strict validation layer

12
00:00:43,673 --> 00:00:47,513
for its Model Context Protocol, or MCP,
schema.

13
00:00:48,253 --> 00:00:51,803
When the browser or the computer-use tool
tries to initialize,

14
00:00:52,353 --> 00:00:57,923
it passes sandboxCwd, which is the current
working directory for the sandbox.

15
00:00:58,673 --> 00:01:05,093
But if that path isn't formatted as a
canonical file triple-slash URI--like

16
00:01:05,173 --> 00:01:11,733
file:///Users/name/projects--it just
instantly

17
00:01:11,813 --> 00:01:18,393
rejects the payload with that -32602
invalid params code.

18
00:01:19,515 --> 00:01:20,405
Okay, but why now?

19
00:01:21,005 --> 00:01:27,265
I mean, standard local paths like, you
know, just slash-Users-slash-something used

20
00:01:27,305 --> 00:01:28,285
to resolve fine.

21
00:01:29,005 --> 00:01:34,745
What changed in the node_repl/js
environment to suddenly start demanding that strict

22
00:01:35,025 --> 00:01:36,505
file triple-slash scheme?

23
00:01:37,340 --> 00:01:40,600
Right, so it's a conflict with custom CLI
overrides.

24
00:01:41,300 --> 00:01:46,280
A lot of us have CODEX_CLI_PATH set in our
environment variables to point to a

25
00:01:46,340 --> 00:01:50,640
custom or maybe an older development build
of the codex-cli server.

26
00:01:51,380 --> 00:01:56,460
But the newer Codex Desktop runtime
expects a specific metadata handshake.

27
00:01:57,200 --> 00:02:00,270
Thanks to Jellypod for helping make this
daily show a reality,

28
00:02:00,280 --> 00:02:01,260
by the way.

29
00:02:01,300 --> 00:02:06,880
But yeah, when Codex Desktop calls out to
that older, un-updated CLI tool pointed to

30
00:02:06,900 --> 00:02:13,560
by CODEX_CLI_PATH, that older binary
doesn't know how to translate or parse the raw

31
00:02:13,600 --> 00:02:19,120
local path string into the canonical file
URI scheme before sending it back over the

32
00:02:19,200 --> 00:02:20,660
JSON-RPC channel.

33
00:02:22,497 --> 00:02:22,498
Ah!

34
00:02:22,497 --> 00:02:23,658
So it's a version mismatch.

35
00:02:24,098 --> 00:02:30,328
The desktop app is talking MCP dialect B,
but your custom CLI path is still speaking

36
00:02:30,368 --> 00:02:34,228
dialect A, and when they try to negotiate
the sandbox setup,

37
00:02:34,268 --> 00:02:36,668
the schema validation just drops the
connection.

38
00:02:37,582 --> 00:02:38,062
Yes!

39
00:02:38,402 --> 00:02:41,982
And it gets worse because once that schema
validation fails,

40
00:02:42,502 --> 00:02:49,302
the parent process throws a secondary MCP
error -10000, saying "Sender process

41
00:02:49,482 --> 00:02:50,902
is not authenticated."

42
00:02:51,542 --> 00:02:53,422
Which, of course, is a total red herring.

43
00:02:54,022 --> 00:02:57,622
It makes you think you have a permissions
or a code-signing issue with your

44
00:02:57,642 --> 00:03:03,362
certificates, when in reality, it's just
that the CLI tool didn't format the sandbox

45
00:03:03,382 --> 00:03:04,662
directory string correctly.

46
00:03:05,358 --> 00:03:07,348
Wow, that's a nasty side effect.

47
00:03:08,068 --> 00:03:12,508
So, if someone is staring at that "not
authenticated" error right now,

48
00:03:12,588 --> 00:03:16,248
how do they actually force it to resolve
back to the stable behavior?

49
00:03:17,045 --> 00:03:21,815
The quickest fix is actually just to
completely unset CODEX_CLI_PATH.

50
00:03:22,425 --> 00:03:26,885
If you clear that environment variable,
Codex Desktop will stop trying to use your

51
00:03:26,925 --> 00:03:29,085
global or custom CLI wrapper.

52
00:03:29,785 --> 00:03:34,955
Instead, it falls back to its own native,
signed, bundled binaries that are packaged

53
00:03:34,985 --> 00:03:37,055
directly inside the desktop application.

54
00:03:37,785 --> 00:03:42,645
Those bundled binaries are guaranteed to
match the expected MCP schema and will

55
00:03:42,705 --> 00:03:47,145
correctly format sandboxCwd as a proper
file URI.

56
00:03:51,274 --> 00:03:51,275
That makes sense.

57
00:03:51,274 --> 00:03:54,625
But speaking of bugs that mess with your
environment, there's another massive issue

58
00:03:54,665 --> 00:03:59,405
we need to talk about, and this one is
actually costing people money.

59
00:03:59,445 --> 00:04:04,885
It's a token-bloat bug in the Bedrock
adapter that's silently eating up token quotas

60
00:04:04,905 --> 00:04:06,065
during streaming sessions.

61
00:04:06,922 --> 00:04:09,132
Oh, the amazon-bedrock adapter?

62
00:04:09,922 --> 00:04:13,142
Is this related to how it handles the
stream completion chunks?

63
00:04:17,973 --> 00:04:17,974
Yes, exactly.

64
00:04:17,973 --> 00:04:20,423
So normally, when you stream a response
from Bedrock, the adapter is supposed to

65
00:04:20,483 --> 00:04:25,443
append the incoming chunks to a single
active message object in the session state.

66
00:04:26,123 --> 00:04:30,703
But right now, there's a bug where
cumulative snapshots of the stream are being

67
00:04:30,783 --> 00:04:34,883
saved as entirely separate, completed
message items in the database.

68
00:04:35,623 --> 00:04:40,663
If you look at your log
database--specifically the thread_dynamic_tools table in

69
00:04:40,803 --> 00:04:46,923
logs_2.sqlite--you will see hundreds of
redundant partial message rows for a single

70
00:04:47,023 --> 00:04:47,403
prompt.

71
00:04:48,605 --> 00:04:52,755
Wait, so instead of saving one message
with, say, five hundred tokens,

72
00:04:53,245 --> 00:04:55,885
it's saving dozens of partial state
snapshots?

73
00:04:56,645 --> 00:05:01,115
So the next time you send a message, the
context window is loading all of those

74
00:05:01,165 --> 00:05:03,985
partial duplicate snapshots from the
database?

75
00:05:07,815 --> 00:05:07,816
Precisely.

76
00:05:07,815 --> 00:05:10,155
The entire history gets sent back up to
Bedrock on the next turn.

77
00:05:10,805 --> 00:05:16,935
So your token usage doesn't just grow
linearly; it balloons exponentially because

78
00:05:16,965 --> 00:05:21,545
the adapter is feeding these massive,
duplicated history blocks back into the model.

79
00:05:22,265 --> 00:05:27,855
It can turn a simple ten-turn chat into a
multi-million token disaster in a matter

80
00:05:27,905 --> 00:05:29,085
of minutes.

81
00:05:29,353 --> 00:05:32,413
That is an incredibly expensive way to
keep track of state.

82
00:05:33,013 --> 00:05:37,163
Is there a temporary patch for that, or do
we just have to wait for an official

83
00:05:37,233 --> 00:05:39,193
release to fix the adapter code?

84
00:05:40,472 --> 00:05:45,102
Right now, you either have to manually
prune those logs_2.sqlite tables if you

85
00:05:45,203 --> 00:05:49,823
notice your latency spiking, or
temporarily switch away from the Bedrock adapter to

86
00:05:49,863 --> 00:05:54,163
a standard Claude or OpenAI endpoint while
the team patches the state accumulation

87
00:05:54,222 --> 00:05:54,563
logic.

88
00:05:55,203 --> 00:05:59,703
And speaking of interface issues, we also
have to talk about the TUI--the terminal

89
00:05:59,803 --> 00:06:00,423
user interface.

90
00:06:01,083 --> 00:06:04,923
Have you tried using the slash-feedback
command in the TUI lately?

91
00:06:05,482 --> 00:06:06,732
Oh, don't get me started.

92
00:06:07,442 --> 00:06:11,362
I tried to submit a bug report through the
TUI using /feedback,

93
00:06:11,882 --> 00:06:15,102
and instead of routing it to the internal
diagnostics endpoint,

94
00:06:15,632 --> 00:06:21,822
the TUI actually sent my local system path
feedback as a raw chat prompt directly to

95
00:06:21,842 --> 00:06:22,482
the LLM!

96
00:06:24,348 --> 00:06:24,418
Yes!

97
00:06:25,078 --> 00:06:27,558
It's a classic command-routing footgun.

98
00:06:28,018 --> 00:06:32,718
In the current terminal interface, the
slash-composer boundary is slightly broken.

99
00:06:33,198 --> 00:06:37,618
If you type /feedback followed by your
message, the parser fails to intercept the

100
00:06:37,658 --> 00:06:42,118
command at the boundary, misses the slash
prefix entirely, and just treats it as a

101
00:06:42,218 --> 00:06:42,998
normal prompt.

102
00:06:43,398 --> 00:06:47,378
So the model ends up trying to interpret
your diagnostic feedback as a query,

103
00:06:47,598 --> 00:06:49,118
which is totally useless.

104
00:06:49,990 --> 00:06:54,830
So the workaround for now is to avoid
using inline arguments with /feedback in the

105
00:06:54,890 --> 00:06:55,430
TUI.

106
00:06:56,150 --> 00:07:02,270
Just type /feedback on its own, hit enter,
and wait for the dedicated diagnostic

107
00:07:02,410 --> 00:07:05,310
prompt block to open up before typing your
logs.

108
00:07:06,070 --> 00:07:10,250
That prevents the parser from getting
confused and routing your raw text to the

109
00:07:10,270 --> 00:07:10,560
model.