You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
DevSpace was losing the workspaceId after MCP reconnects #339
DevSpace was losing the workspaceId after MCP reconnects or server restarts because the conversation-to-workspace binding was not being properly restored.
i'm also encounting the same issue - ChatGPT will report it losts the session and unable to do edition etc, and that really hurts the experience.
It seems related with the situation when we have multiple chat sessions with the same MCP endpoint, the probabality of losing workspaceId will very high. I just avoid using multiple sessions now.
@grokking88@amrpyt can you guys try the v1.1 beta and see if it still happens there?
The older DevSpace version used a stateful architecture, while the latest one uses a stateless MCP architecture. Not sure if that change is related though, this could also be on ChatGPT’s side, depending on how it preserves tool call results in the model context across reconnects.
Tested on v1.1.0-beta.4. Confirms this is client-side (ChatGPT connector), not
DevSpace:
Relogin to ChatGPT alone did NOT fix it — same "workspaceId"/schema mismatch
persisted across a fresh login.
Verified DevSpace's own schema is internally consistent: open_workspace's
output and read/write/edit/bash's input all declare workspace_id
(snake_case) with no camelCase compatibility alias anywhere in the source.
Fully deleting the connector (not just disconnect) and re-adding it with the
same MCP URL fixed it immediately. bash/read/write/edit/show_changes all
succeeded right after reconnecting, in the same chat, without a new session.
So the schema ChatGPT was using was stale at the connector registration
level, not the conversation level — a plain relogin or new chat doesn't
refresh it, only a full disconnect+reconnect does.
Inside plugin settings, where you can view all the tool schemas, at the bottom is a "refresh" button that can reload tools from MCP. You will most likely still need a new conversation, chatgpt freezes tooling in the conversation.
Tested on v1.1.0-beta.4. Confirms this is client-side (ChatGPT connector), not DevSpace:
Relogin to ChatGPT alone did NOT fix it — same "workspaceId"/schema mismatch
persisted across a fresh login.
Verified DevSpace's own schema is internally consistent: open_workspace's
output and read/write/edit/bash's input all declare workspace_id
(snake_case) with no camelCase compatibility alias anywhere in the source.
Fully deleting the connector (not just disconnect) and re-adding it with the
same MCP URL fixed it immediately. bash/read/write/edit/show_changes all
succeeded right after reconnecting, in the same chat, without a new session.
So the schema ChatGPT was using was stale at the connector registration level, not the conversation level — a plain relogin or new chat doesn't refresh it, only a full disconnect+reconnect does.
Reinstall the connector will fix this issue but it won't work for very long time, i had the same error just after creating two new chats.
The HTTP requests received by devspace nearby the error is like:
GET 200 OK /.well-known/oauth-authorization-server
GET 404 Not F… /.well-known/openid-configuration
Fixed: the conversation-to-checkout binding is persisted and restored on open_workspace (#128), and the cached pre-snake_case workspaceId argument is accepted (a59a06e9). Remaining "lost mid-chat" reports trace to ChatGPT's cached connector state; see #140.
Activity
grokking88 commentedon Sep 11, 2026
i'm also encounting the same issue - ChatGPT will report it losts the session and unable to do edition etc, and that really hurts the experience.
grokking88 commentedon Sep 15, 2026
It seems related with the situation when we have multiple chat sessions with the same MCP endpoint, the probabality of losing workspaceId will very high. I just avoid using multiple sessions now.
Waishnav commentedon Sep 15, 2026
@grokking88 @amrpyt can you guys try the v1.1 beta and see if it still happens there?
The older DevSpace version used a stateful architecture, while the latest one uses a stateless MCP architecture. Not sure if that change is related though, this could also be on ChatGPT’s side, depending on how it preserves tool call results in the model context across reconnects.
AnisDev522 commentedon Sep 17, 2026
Tested on v1.1.0-beta.4. Confirms this is client-side (ChatGPT connector), not
DevSpace:
persisted across a fresh login.
output and read/write/edit/bash's input all declare
workspace_id(snake_case) with no camelCase compatibility alias anywhere in the source.
same MCP URL fixed it immediately. bash/read/write/edit/show_changes all
succeeded right after reconnecting, in the same chat, without a new session.
So the schema ChatGPT was using was stale at the connector registration
level, not the conversation level — a plain relogin or new chat doesn't
refresh it, only a full disconnect+reconnect does.
DormantDaemon commentedon Sep 17, 2026
Inside plugin settings, where you can view all the tool schemas, at the bottom is a "refresh" button that can reload tools from MCP. You will most likely still need a new conversation, chatgpt freezes tooling in the conversation.
grokking88 commentedon Sep 17, 2026
Reinstall the connector will fix this issue but it won't work for very long time, i had the same error just after creating two new chats.
The HTTP requests received by devspace nearby the error is like:
amrpyt commentedon Sep 21, 2026
Did u find any solution? @grokking88
Waishnav commentedon Oct 27, 2026
Fixed: the conversation-to-checkout binding is persisted and restored on
open_workspace(#128), and the cached pre-snake_caseworkspaceIdargument is accepted (a59a06e9). Remaining "lost mid-chat" reports trace to ChatGPT's cached connector state; see #140.