fix(mcp-store): disable MCPs from local config file#1601
fix(mcp-store): disable MCPs from local config file#1601
Conversation
| } | ||
| await this.loadSettings(); | ||
| this.initialized = true; | ||
| // No-op: settings are loaded in the constructor. Kept async to |
There was a problem hiding this comment.
I don't like this, but I couldn't find an elegant solution without jacking up the BaseSettingsManager interface (and subsequently, Claude adapter)
|
to clarify, this will mean users can't use any of the MCPs they have configured with codex? how will they use MCPs with codex then? i think as a user it'd be frustrating if i had a bunch of MCPs all set up and ready to go with codex native and then they didn't work or i had to set them all up again in ph code |
|
@adboio yeah, I was wondering what experience we wanted there. From how I understand it, we aren't importing the MCP servers from the user's Claude configs, so I mirrored that behavior with Codex. If we decide we want to bring their MCP integrations into PH Code, we would want to add a whole UI for that. Also, not sure how that'd work with sandbox agents. |
k11kirky
left a comment
k11kirky
left a comment
There was a problem hiding this comment.
approving to unblock but added a question
| } | ||
| await this.loadSettings(); | ||
| this.initialized = true; | ||
| // No-op: settings are loaded in the constructor. Kept async to |
|
|
||
| // Disable the user's local MCPs one-by-one so Codex only uses the MCPs we | ||
| // provide via ACP. We can't use `-c mcp_servers={}` because that makes Codex | ||
| // ignore MCPs entirely, including the ones we inject later. |
There was a problem hiding this comment.
hmm - im not sure we want to remove all locals right? only if they conflict we should favor ours
|
ahh i assumed we were bringing in claude MCPs, i don't use very many so i guess i never noticed lol is this actively causing problems? if not, i think we should reconsider and try to find a way to bring in MCPs from both codex + claude instead of disabling them for both |
3 participants
Problem
Codex sessions in PostHog Code were inheriting
[mcp_servers.*]entries from the user's personal~/.codex/config.toml, causing conflicts with the servers we intentionally supply via the MCP store.Changes
mcp_servers.*entries, and pass a command to disable each individually when spawningcodex-acpCodexSettingsManagerto load settings upon initializationHow did you test this?