So, if you've been working on your local automation setup this week and suddenly hit
an MCP error -32602, you are definitely not alone.
It's this super frustrating issue where the logs start screaming that sandboxCwd
must use the file URI scheme.
Maya, I spent about three hours yesterday digging into slash_input.rs because of
this exact validation failure.
Oh, wait, slash_input.rs?
So this is actually failing deep in the input parsing before it even hits the
sandbox runner?
Exactly.
What's happening is that Codex Desktop has this incredibly strict validation layer
for its Model Context Protocol, or MCP, schema.
When the browser or the computer-use tool tries to initialize,
it passes sandboxCwd, which is the current working directory for the sandbox.
But if that path isn't formatted as a canonical file triple-slash URI--like
file:///Users/name/projects--it just instantly
rejects the payload with that -32602 invalid params code.
Okay, but why now?
I mean, standard local paths like, you know, just slash-Users-slash-something used
to resolve fine.
What changed in the node_repl/js environment to suddenly start demanding that strict
file triple-slash scheme?
Right, so it's a conflict with custom CLI overrides.
A lot of us have CODEX_CLI_PATH set in our environment variables to point to a
custom or maybe an older development build of the codex-cli server.
But the newer Codex Desktop runtime expects a specific metadata handshake.
Thanks to Jellypod for helping make this daily show a reality,
by the way.
But yeah, when Codex Desktop calls out to that older, un-updated CLI tool pointed to
by CODEX_CLI_PATH, that older binary doesn't know how to translate or parse the raw
local path string into the canonical file URI scheme before sending it back over the
JSON-RPC channel.
Ah!
So it's a version mismatch.
The desktop app is talking MCP dialect B, but your custom CLI path is still speaking
dialect A, and when they try to negotiate the sandbox setup,
the schema validation just drops the connection.
Yes!
And it gets worse because once that schema validation fails,
the parent process throws a secondary MCP error -10000, saying "Sender process
is not authenticated."
Which, of course, is a total red herring.
It makes you think you have a permissions or a code-signing issue with your
certificates, when in reality, it's just that the CLI tool didn't format the sandbox
directory string correctly.
Wow, that's a nasty side effect.
So, if someone is staring at that "not authenticated" error right now,
how do they actually force it to resolve back to the stable behavior?
The quickest fix is actually just to completely unset CODEX_CLI_PATH.
If you clear that environment variable, Codex Desktop will stop trying to use your
global or custom CLI wrapper.
Instead, it falls back to its own native, signed, bundled binaries that are packaged
directly inside the desktop application.
Those bundled binaries are guaranteed to match the expected MCP schema and will
correctly format sandboxCwd as a proper file URI.
That makes sense.
But speaking of bugs that mess with your environment, there's another massive issue
we need to talk about, and this one is actually costing people money.
It's a token-bloat bug in the Bedrock adapter that's silently eating up token quotas
during streaming sessions.
Oh, the amazon-bedrock adapter?
Is this related to how it handles the stream completion chunks?
Yes, exactly.
So normally, when you stream a response from Bedrock, the adapter is supposed to
append the incoming chunks to a single active message object in the session state.
But right now, there's a bug where cumulative snapshots of the stream are being
saved as entirely separate, completed message items in the database.
If you look at your log database--specifically the thread_dynamic_tools table in
logs_2.sqlite--you will see hundreds of redundant partial message rows for a single
prompt.
Wait, so instead of saving one message with, say, five hundred tokens,
it's saving dozens of partial state snapshots?
So the next time you send a message, the context window is loading all of those
partial duplicate snapshots from the database?
Precisely.
The entire history gets sent back up to Bedrock on the next turn.
So your token usage doesn't just grow linearly; it balloons exponentially because
the adapter is feeding these massive, duplicated history blocks back into the model.
It can turn a simple ten-turn chat into a multi-million token disaster in a matter
of minutes.
That is an incredibly expensive way to keep track of state.
Is there a temporary patch for that, or do we just have to wait for an official
release to fix the adapter code?
Right now, you either have to manually prune those logs_2.sqlite tables if you
notice your latency spiking, or temporarily switch away from the Bedrock adapter to
a standard Claude or OpenAI endpoint while the team patches the state accumulation
logic.
And speaking of interface issues, we also have to talk about the TUI--the terminal
user interface.
Have you tried using the slash-feedback command in the TUI lately?
Oh, don't get me started.
I tried to submit a bug report through the TUI using /feedback,
and instead of routing it to the internal diagnostics endpoint,
the TUI actually sent my local system path feedback as a raw chat prompt directly to
the LLM!
Yes!
It's a classic command-routing footgun.
In the current terminal interface, the slash-composer boundary is slightly broken.
If you type /feedback followed by your message, the parser fails to intercept the
command at the boundary, misses the slash prefix entirely, and just treats it as a
normal prompt.
So the model ends up trying to interpret your diagnostic feedback as a query,
which is totally useless.
So the workaround for now is to avoid using inline arguments with /feedback in the
TUI.
Just type /feedback on its own, hit enter, and wait for the dedicated diagnostic
prompt block to open up before typing your logs.
That prevents the parser from getting confused and routing your raw text to the
model.