Repository navigation
After updating to latest, ChatGPT says devspace is not exposed #140
Description
Activity
+1
It works fine in a new ChatGPT conversation, but after a few turns DevSpace can suddenly disappear.got error:
FORBIDDEN: This conversation does not support developer MCPsOpening a new conversation makes it work again.
Found similar issues as well. It happens when the handoff between chat and work mode happens, it seems to disable developer MCPs.
I can reproduce this consistently with DevSpace v1.0.7 on ChatGPT:
- Start a new chat → DevSpace works normally.
- Send a second message in the same chat → DevSpace returns
FORBIDDEN: This conversation does not support developer MCPs. - Start another new chat → DevSpace works again for the first turn.
Multiple DevSpace calls within a single turn work correctly. The failure only happens across ChatGPT conversation turns.
I only run into this issue when I use DevSpace and then use another plugin, like Github, and try to go back to DevSpace. Or if I start a conversation with one plugin like Github and try to use DevSpace. My assumption was that the other plugins don't support developer MCPs so DevSpace gets blocked. I've just been keep DevSpace conversations isolated from other plugin usage.
I only run into this issue when I use DevSpace and then use another plugin, like Github, and try to go back to DevSpace. Or if I start a conversation with one plugin like Github and try to use DevSpace. My assumption was that the other plugins don't support developer MCPs so DevSpace gets blocked. I've just been keep DevSpace conversations isolated from other plugin usage.
I'd agree, but this doesn't happen to me with the Sequential Thinking MCP. I can use it with other plugins in the same session.
@SapitoSucio it looks like it works fine when you don't give permanent write permission. Try by giving access only during the conversation or once when you need it.
I’ve found a similar issue. It looks like it’s on the ChatGPT side, they disable tools in Chat and force us to use Work. A quick workaround is to fork/branch the chat from where it says “Devspace not available.” In the new forked chat, the tools should work normally again.
I had the same problem; reverting to version 1.0.5 fixed it. According to ChatGPT, the issue is that v1.0.6 has just added conversation-aware reuse via _meta[“openai/session”]. Unfortunately, I can't use versions higher than this until this is fixed.
@milkmiraclework-alt is this still reproducible in v1.0.8? I’m able to use it in long conversations with multiple turn
Its very weird, chatgpt mcp client implementation keeps on changing they seems to gatekeep alot these days (reason being compute crises so it’s understandable)
@milkmiraclework-alt is this still reproducible in v1.0.8? I’m able to use it in long conversations with multiple turn
Its very weird, chatgpt mcp client implementation keeps on changing they seems to gatekeep alot these days (reason being compute crises so it’s understandable)
Yes, the problem definitely went away in version 1.0.8—at least for me. Thanks!
I can still reproduce this on DevSpace v1.0.8, and I instrumented the remote MCP server to determine where the failure occurs.
Reproduction
Same ChatGPT conversation, remote MCP over HTTPS/OAuth:
- Turn 1:
open_workspace,read,browser_tabsall succeeded. - Turn 2: calls still succeeded.
- Turn 3:
open_workspace,read, andbrowser_tabsall failed withResource not found. - Starting a new ChatGPT conversation restores the tools temporarily.
Server-side evidence
The failing turn occurred around
2026-09-12 03:19 +08:00(2026-09-11 19:19 UTC).I added request-level instrumentation at the MCP HTTP entry point and dispatch layer. For successful turns, the server recorded:
HTTP ingress -> MCP dispatch -> adapter creation -> tools/call -> tool handler -> HTTP 200For the failing turn:
- no
mcp_ingress - no
mcp_dispatch - no
tools/call - no adapter creation
- no tool handler invocation
- no HTTP request/status
- no JSON-RPC response
- the server logs contained zero occurrences of
Resource not found
The last successful ChatGPT MCP request was at
2026-09-11 19:15:20.497Z.Interestingly, ChatGPT still showed the MCP tool schemas as available during the failing turn, but the direct tool invocations generated no traffic to the MCP server at all.
I also repeated the test against a stateless/per-request MCP variant and observed the same conversation-level failure pattern.
Conclusion
For this reproduction, the failure happens before the request reaches DevSpace/Cloudflare, which strongly points to a ChatGPT conversation-scoped MCP connector / tool-resource binding / remote-dispatch issue rather than DevSpace's tool handlers, workspace logic, or server-side session transport.
So v1.0.8 does not appear to eliminate the issue universally.
- Turn 1:
@jackchan1234 try beta release of v1.1
I encountered a related upgrade failure mode that may be useful when diagnosing ChatGPT integration failures.
Environment
- Windows x64
- ChatGPT custom MCP app
@waishnav/devspace1.1.0-beta.4tools.mode = "codex"
No private workspace paths or tunnel identifiers are included below.
Observed behavior
After upgrading from the older tool surface to the current v1.1 Codex-style surface, the DevSpace server and the tool definitions retained by the ChatGPT app could become inconsistent.
The server-side
open_workspaceresult used:{ "workspace_id": "ws_..." }and the current Codex tool surface exposes tools such as:
open_workspace read apply_patch exec_command write_stdin show_changesHowever, an existing ChatGPT MCP tool snapshot could still expose the older surface:
open_workspace read write edit bashwith follow-up calls using a
workspaceIdfield.This produced a partially working connection:
open_workspace -> succeeds read -> workspace_id: expected string, received undefined bash -> Tool bash not foundOpening a new ChatGPT conversation alone was not sufficient in the reproduction because the registered app/tool definition itself still represented the older schema.
Important distinction
This may partly be host-side tool-schema caching rather than a DevSpace server defect.
From the user's perspective, though, a DevSpace upgrade can leave the integration in a misleading half-compatible state:
open_workspaceworks while subsequent tools fail with unrelated-looking validation/tool-not-found errors.Suggested improvements
It would help if the v1.0 -> v1.1 upgrade path explicitly called out the MCP tool-contract change, especially:
workspaceId -> workspace_id bash -> exec_command write/edit -> apply_patch + write_stdin for long-running commandsPossible DevSpace-side mitigations:
- Add a prominent upgrade note telling ChatGPT users to refresh/re-register the MCP app/tool definitions after this breaking tool-surface change.
- Add a
doctordiagnostic or documented check for an old host tool surface. - If practical, temporarily accept
workspaceIdas a compatibility alias while emitting a deprecation warning. - Return a more actionable error when an old tool name/schema is detected, e.g.
This client appears to be using a pre-v1.1 MCP tool schema; refresh the registered DevSpace tools.
The main issue is not that the new Codex tool surface is wrong; it is that a stale host registration fails in a way that looks like multiple unrelated DevSpace bugs.
- added a commit that references this issue
on Sep 27, 2026
DevSpace becomes unavailable after the first interaction in the same chat
When I create a new ChatGPT chat/session and ask ChatGPT to use DevSpace, it works correctly during the initial interaction.
However, after ChatGPT finishes that first response, DevSpace becomes unavailable on the next interaction in the same chat.
Initially, I thought this was related to leaving the conversation inactive for several minutes. After further testing, I found that inactivity does not appear to be relevant. The issue happens consistently after the first interaction with DevSpace, even if I send the next message immediately.
Steps to reproduce
Expected behavior
Once DevSpace is available in a chat and has been successfully used, it should remain available for subsequent interactions in the same conversation.
Actual behavior
DevSpace is available during the first interaction, but after ChatGPT completes that response, it is no longer exposed to ChatGPT on subsequent turns in the same chat.
Starting a new chat makes DevSpace available again, but only for the first interaction before the same problem repeats.
This makes multi-turn development sessions with DevSpace effectively impossible, since continuing the work requires starting a new chat after every DevSpace interaction.