Skip to content

After updating to latest, ChatGPT says devspace is not exposed #140

Open
Open
After updating to latest, ChatGPT says devspace is not exposed#140

Description

@SapitoSucio
SapitoSucio
opened on Aug 7, 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

  1. Start a new ChatGPT chat.
  2. Ask ChatGPT to use DevSpace for a development task.
  3. ChatGPT successfully accesses and uses DevSpace.
  4. Wait for ChatGPT to finish its response.
  5. Send another message in the same chat asking it to continue working with DevSpace.
  6. ChatGPT reports that DevSpace is no longer exposed or available to it.

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.

Activity

  1. MagicalWater commented on Aug 9, 2026

    @MagicalWater
    MagicalWater
    on Aug 9, 2026

    +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 MCPs

    Opening a new conversation makes it work again.

  2. Toys0125 commented on Aug 12, 2026

    @Toys0125
    Toys0125
    on Aug 12, 2026

    Found similar issues as well. It happens when the handoff between chat and work mode happens, it seems to disable developer MCPs.

  3. Rutenioum commented on Aug 14, 2026

    @Rutenioum
    Rutenioum
    on Aug 14, 2026

    I can reproduce this consistently with DevSpace v1.0.7 on ChatGPT:

    1. Start a new chat → DevSpace works normally.
    2. Send a second message in the same chat → DevSpace returns FORBIDDEN: This conversation does not support developer MCPs.
    3. 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.

  4. DormantDaemon commented on Aug 16, 2026

    @DormantDaemon
    DormantDaemon
    on Aug 16, 2026

    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.

  5. chdlc commented on Aug 16, 2026

    @chdlc
    chdlc
    on Aug 16, 2026

    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.

  6. chdlc commented on Aug 16, 2026

    @chdlc
    chdlc
    on Aug 16, 2026

    @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.

  7. Bhavik-ag commented on Aug 19, 2026

    @Bhavik-ag
    Bhavik-ag
    on Aug 19, 2026

    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.

  8. milkmiraclework-alt commented on Sep 1, 2026

    @milkmiraclework-alt
    milkmiraclework-alt
    on Sep 1, 2026

    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.

  9. Waishnav commented on Sep 6, 2026

    @Waishnav
    Waishnav
    on Sep 6, 2026
    Owner

    @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)

  10. milkmiraclework-alt commented on Sep 7, 2026

    @milkmiraclework-alt
    milkmiraclework-alt
    on Sep 7, 2026

    @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!

  11. jackchan1234 commented on Sep 11, 2026

    @jackchan1234
    jackchan1234
    on Sep 11, 2026 – with ChatGPT Codex Connector

    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_tabs all succeeded.
    • Turn 2: calls still succeeded.
    • Turn 3: open_workspace, read, and browser_tabs all failed with Resource 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 200

    For 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.

  12. Waishnav commented on Sep 13, 2026

    @Waishnav
    Waishnav
    on Sep 13, 2026
    Owner

    @jackchan1234 try beta release of v1.1

  13. wcf778 commented on Sep 20, 2026

    @wcf778
    wcf778
    on Sep 20, 2026
    Contributor

    I encountered a related upgrade failure mode that may be useful when diagnosing ChatGPT integration failures.

    Environment

    • Windows x64
    • ChatGPT custom MCP app
    • @waishnav/devspace 1.1.0-beta.4
    • tools.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_workspace result used:

    {
  "workspace_id": "ws_..."
}

    and the current Codex tool surface exposes tools such as:

    open_workspace
read
apply_patch
exec_command
write_stdin
show_changes

    However, an existing ChatGPT MCP tool snapshot could still expose the older surface:

    open_workspace
read
write
edit
bash

    with follow-up calls using a workspaceId field.

    This produced a partially working connection:

    open_workspace -> succeeds

read ->
workspace_id: expected string, received undefined

bash ->
Tool bash not found

    Opening 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_workspace works 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 commands

    Possible DevSpace-side mitigations:

    1. Add a prominent upgrade note telling ChatGPT users to refresh/re-register the MCP app/tool definitions after this breaking tool-surface change.
    2. Add a doctor diagnostic or documented check for an old host tool surface.
    3. If practical, temporarily accept workspaceId as a compatibility alias while emitting a deprecation warning.
    4. 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.

  14. SoloistHart
    added a commit that references this issue on Sep 27, 2026

    设置「发布」：B 站 Cookie 提到最上面 (Waishnav#140)

    e8f81cd

  15. DDINGDD commented on Oct 11, 2026

    @DDINGDD
    DDINGDD
    on Oct 11, 2026

    Confirming this issue persists for me on DevSpace v1.0.8 (October 2026). In a ChatGPT conversation, DevSpace tools work in an earlier reply but disappear in a later reply, with ChatGPT stating no DevSpace tool entry points are available. Local Windows checks: DevSpace Server scheduled task is Running; 127.0.0.1:7676 is listening; open_workspace and exec_command work when exposed. This appears intermittent and conversation-scoped, not a continuously offline server. I have not verified whether failing turns reach the MCP server. Is there a verified fix or workaround in v1.1 or later, and should users refresh their registered ChatGPT MCP tool schemas when updating?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions