1
00:00:00,220 --> 00:00:02,980
Thanks to Jellypod for helping make this
daily show a reality.

2
00:00:03,400 --> 00:00:04,019
Let's get into it.

3
00:00:04,900 --> 00:00:09,960
If you run local MCP servers with Codex,
you've probably noticed that every new chat

4
00:00:10,020 --> 00:00:14,160
or subagent thread can spin up its own
copy of each stdio helper.

5
00:00:14,900 --> 00:00:20,480
Codex 0.166.0 starts to change that, and
follow up work is landing in the

6
00:00:20,780 --> 00:00:23,260
0.167.0 alpha previews.

7
00:00:24,340 --> 00:00:25,140
Here's the change.

8
00:00:25,620 --> 00:00:27,000
Three pull requests matter.

9
00:00:27,560 --> 00:00:33,840
Number 57210 adds opt in protocol
discovery for local stdio MCP servers.

10
00:00:34,400 --> 00:00:40,340
Number 57211 shares eligible local stdio
MCP connections across chats.

11
00:00:40,840 --> 00:00:46,140
And number 57196 isolates MCP inputs and
timeouts for callers that share a

12
00:00:46,180 --> 00:00:46,600
connection.

13
00:00:47,040 --> 00:00:50,000
The sharing is gated behind an
experimental feature flag called

14
00:00:50,180 --> 00:00:54,680
mcp_connection_sharing, and the discovery
piece is a probe using a method called

15
00:00:54,840 --> 00:00:56,140
server/discover.

16
00:00:56,758 --> 00:00:58,498
This builds on things we've covered
before.

17
00:00:58,878 --> 00:01:04,338
A few episodes back, in the 0.164.0
episode on enterprise MCP sign in,

18
00:01:04,778 --> 00:01:08,278
the story was about how Codex
authenticates to MCP servers.

19
00:01:08,838 --> 00:01:13,598
Then 0.166.0 shipped the standalone exec
server and resume fixes.

20
00:01:14,258 --> 00:01:19,098
This is the next layer of the same
infrastructure story: not just how Codex connects

21
00:01:19,118 --> 00:01:23,358
to an MCP server, but how many connections
it makes to the same local process.

22
00:01:23,947 --> 00:01:24,567
Why does it matter?

23
00:01:25,087 --> 00:01:29,007
Think about what a stdio MCP server
actually is.

24
00:01:29,607 --> 00:01:33,967
Codex launches it as a child process and
talks to it over standard input and output.

25
00:01:34,467 --> 00:01:35,847
That's a one to one relationship.

26
00:01:36,507 --> 00:01:41,187
So if you have a heavy helper, say a
SQLite analyzer, a language server wrapper,

27
00:01:41,427 --> 00:01:46,607
or a custom tool daemon, and you open
three chats, or one chat that fans out into

28
00:01:46,647 --> 00:01:49,867
subagents, you can end up with three
copies of that helper.

29
00:01:50,487 --> 00:01:54,427
Each one holds its own memory, its own
caches, its own CPU appetite.

30
00:01:55,087 --> 00:01:59,547
The pattern we've been seeing is CPU and
memory bloat whenever people run threads

31
00:01:59,587 --> 00:02:00,167
concurrently.

32
00:02:00,822 --> 00:02:02,462
Connection sharing aims to fix that.

33
00:02:02,922 --> 00:02:06,842
A single local helper process can serve
multiple client sessions at once.

34
00:02:07,322 --> 00:02:10,202
And that's where pull request 57196 comes
in.

35
00:02:10,742 --> 00:02:14,202
Sharing a process is only safe if callers
can't step on each other.

36
00:02:14,602 --> 00:02:18,162
So that change isolates the inputs, the
request and response lifecycles,

37
00:02:18,522 --> 00:02:19,982
and the timeouts between callers.

38
00:02:20,502 --> 00:02:24,602
If one chat's tool call hangs and times
out, it shouldn't poison the connection for

39
00:02:24,642 --> 00:02:25,142
the others.

40
00:02:25,522 --> 00:02:29,242
That's the design goal, and it's worth
testing against your own servers rather than

41
00:02:29,302 --> 00:02:29,722
assuming.

42
00:02:30,363 --> 00:02:31,483
Now, how do you try it?

43
00:02:31,903 --> 00:02:34,343
The flag is experimental, so treat it that
way.

44
00:02:35,083 --> 00:02:40,303
In your Codex configuration, you set
mcp_connection_sharing equal to true.

45
00:02:41,143 --> 00:02:46,283
Alongside that, there's a newer protocol
setting named mcp_2026_07_28,

46
00:02:46,823 --> 00:02:48,683
which turns on the modern discovery
handshake.

47
00:02:49,503 --> 00:02:51,903
Eligible servers negotiate sharing through
that handshake.

48
00:02:52,443 --> 00:02:56,383
Codex sends the server/discover probe, and
a server that understands it can report

49
00:02:56,403 --> 00:02:58,603
its compatibility and capability
boundaries.

50
00:02:59,203 --> 00:03:01,623
A server that doesn't opt in should simply
stay unshared.

51
00:03:02,280 --> 00:03:05,720
A practical workflow: pick one server you
can afford to break.

52
00:03:06,140 --> 00:03:08,160
Turn the flag on in a scratch profile.

53
00:03:08,800 --> 00:03:13,060
Open two threads that both call that
server, then look at your process list.

54
00:03:13,700 --> 00:03:17,440
If sharing is working, you should see one
helper process, not two.

55
00:03:18,180 --> 00:03:22,480
Then deliberately trigger a slow tool call
in one thread and confirm the other

56
00:03:22,500 --> 00:03:23,760
thread stays responsive.

57
00:03:24,440 --> 00:03:28,080
That second test is the one that tells you
whether isolation holds for your helper.

58
00:03:28,818 --> 00:03:31,818
Now the caveats, and there are real ones.

59
00:03:32,638 --> 00:03:39,338
GitHub issue 57480 reports that enabling
mcp_connection_sharing can break required

60
00:03:39,498 --> 00:03:43,258
legacy stdio servers that don't support
modern discovery.

61
00:03:44,118 --> 00:03:44,798
Here's the failure.

62
00:03:45,298 --> 00:03:47,998
Codex sends the server/discover probe.

63
00:03:48,498 --> 00:03:53,538
A well behaved legacy server would answer
with a standard JSON RPC method not found

64
00:03:53,598 --> 00:03:55,598
error, and Codex would fall back.

65
00:03:56,478 --> 00:04:00,018
But some unmarked legacy helpers answer
with an empty result,

66
00:04:00,538 --> 00:04:01,558
just curly braces.

67
00:04:02,278 --> 00:04:06,098
According to the issue, Codex then panics
with a message saying it expected an

68
00:04:06,158 --> 00:04:09,458
initialized result but received an empty
result object.

69
00:04:10,238 --> 00:04:13,818
Initialization fails, and thread/start
never succeeds.

70
00:04:14,258 --> 00:04:21,218
So a required server can stop you from
starting a thread at all.

71
00:04:21,780 --> 00:04:22,920
There's a second gotcha.

72
00:04:23,560 --> 00:04:26,740
Say you decide to pin a server to an older
protocol using the

73
00:04:26,780 --> 00:04:33,460
CODEX_MCP_PROTOCOL_VERSION environment
variable, set to the June 2025

74
00:04:33,500 --> 00:04:34,160
version string.

75
00:04:34,900 --> 00:04:40,840
If mcp_2026_07_28 is active at the same
time, you get a hard startup failure.

76
00:04:41,460 --> 00:04:45,320
The message says the protocol version is
unsupported and that Codex expected the

77
00:04:45,480 --> 00:04:47,560
2026 07 28 version.

78
00:04:48,180 --> 00:04:50,240
Those two settings conflict, so pick one.

79
00:04:50,905 --> 00:04:52,025
So the guidance is simple.

80
00:04:52,345 --> 00:04:55,485
Don't flip this on globally if you depend
on legacy helpers.

81
00:04:56,105 --> 00:04:59,465
Keep those helpers private, meaning not
part of a shared configuration,

82
00:05:00,005 --> 00:05:03,965
or make sure your server answers unknown
methods with a proper method not found

83
00:05:04,105 --> 00:05:05,705
error instead of an empty object.

84
00:05:06,265 --> 00:05:10,265
If you maintain an MCP server yourself,
that second fix is about three lines,

85
00:05:10,445 --> 00:05:11,505
and it's worth doing now.

86
00:05:12,153 --> 00:05:16,293
A few smaller things from 0.166.0 worth a
mention.

87
00:05:17,013 --> 00:05:20,673
First, codex doctor now takes a network
only flag.

88
00:05:21,213 --> 00:05:24,813
It runs focused diagnostics on
configuration, connectivity,

89
00:05:25,073 --> 00:05:30,313
proxies, endpoints, and WebSocket
behavior, without the slower local environment and

90
00:05:30,373 --> 00:05:31,293
filesystem checks.

91
00:05:32,053 --> 00:05:35,793
If you're behind a corporate proxy and
something's flaky, that's your first command.

92
00:05:36,780 --> 00:05:38,320
Second, a macOS fix.

93
00:05:38,720 --> 00:05:42,720
The standalone binary update cleanup now
handles installations that are currently in

94
00:05:42,860 --> 00:05:45,760
use, and paths that contain non ASCII
characters.

95
00:05:46,380 --> 00:05:49,840
If an update left stale files on your Mac
before, that's likely the reason.

96
00:05:50,548 --> 00:05:54,128
Third, Markdown now renders consistently
in async questions,

97
00:05:54,308 --> 00:05:56,628
choices, answers, and transcript replies.

98
00:05:57,208 --> 00:06:01,128
Small, but it removes some visual noise
when Codex asks you something mid task.

99
00:06:01,818 --> 00:06:03,238
And one distribution note.

100
00:06:03,578 --> 00:06:10,558
The PyPI packages are still lagging at
0.163.0, while npm and the direct curl

101
00:06:10,598 --> 00:06:17,438
installers have 0.166.0, with early
0.167.0 alpha tags also live.

102
00:06:18,098 --> 00:06:20,718
If you installed through pip and wonder
why none of this shows up,

103
00:06:21,038 --> 00:06:21,438
that's why.

104
00:06:21,978 --> 00:06:24,018
Switch install channels before you test
any of this.

105
00:06:24,655 --> 00:06:29,335
The takeaway: connection sharing is a
promising fix for duplicate stdio processes,

106
00:06:29,815 --> 00:06:33,495
but it's experimental and issue 57480 is
open.

107
00:06:34,015 --> 00:06:40,115
Try it on a disposable setup, verify your
legacy servers, and watch the 0.167.0

108
00:06:40,195 --> 00:06:41,095
alphas for fixes.

109
00:06:41,595 --> 00:06:43,315
That's the Codex Changelog for today.