Document ChatGPT Pro lane app-tool caveat

[aaamosh]

First: this is a very interesting project. We are actively testing it as a way to give ChatGPT a real local coding workspace through DevSpace.

I found a ChatGPT model-lane caveat that may be worth documenting. This may not be a DevSpace bug; it looks more like ChatGPT Apps SDK / ChatGPT product behavior. Still, from a DevSpace user's point of view it can look like DevSpace is attached but broken.

What worked

In a ChatGPT web conversation with the DevSpace app attached:

• Composer model setting: GPT-5.5 Extra High
• The app pill was visible.
• The model used DevSpace successfully.
• DevSpace service logs showed openai-mcp/1.0.0, MCP sessions, open_workspace, and a read-only bash call.
• The model listed the workspace root correctly.

So GPT-5.5 Extra High can use DevSpace tools in this setup.

What did not work

In the same ChatGPT web session, with the same DevSpace app pill still attached:

• Composer model setting: Pro Extended / GPT-5.5 Pro
• Prompt asked for a safe read-only probe: run printf PRO_LANE_PROBE through DevSpace bash.
• The model answered that the current interface did not allow it to call DevSpace_samsnote.bash.
• During that Pro response, no new openai-mcp request and no DevSpace tool_call reached the local service.

This means the app pill being visible is not sufficient proof that the active ChatGPT model lane received callable DevSpace tools.

Why this matters

One of the exciting use cases for DevSpace is using ChatGPT's strongest Pro modes for coding against a real local workspace. If Pro lanes currently show the app in the UI but do not pass the app tools into the model runtime, users may think DevSpace itself is broken.

Suggested doc note

Something like:

ChatGPT model lanes can differ in how they receive custom app/MCP tools. Verify actual DevSpace tool use by checking for MCP calls in the DevSpace service logs; the visible app pill alone is not enough. In current testing, Medium / GPT-5.5 Extra High worked, while GPT-5.5 Pro / Pro Extended showed the app pill but did not expose callable DevSpace tools.

Happy to provide more logs or test a recommended metadata/config change if there is one.

[aaamosh]

Thanks again for building DevSpace, this is a very interesting direction and we are actively testing it.

Additional evidence from our side: in a controlled ChatGPT web A/B test through the same connected DevSpace app, Extra High successfully called the MCP server (openai-mcp/1.0.0, open_workspace, then read-only bash). In the same chat with the same visible app pill attached, switching to Pro Extended produced a captured response where the model said it did not have access to the DevSpace tool / DevSpace_samsnote.bash and did not show a tool-call UI. Later MCP traffic in the same conversation may belong to manual follow-up probes, so I would treat positive/negative model-lane claims as needing timestamp-isolated prompt/response + service log evidence.

This appears to match current OpenAI product behavior rather than a local DevSpace transport failure:

• OpenAI Help Center, GPT-5.5 in ChatGPT: https://help.openai.com/articles/11909943
• OpenAI Developer Mode docs: https://developers.openai.com/api/docs/guides/developer-mode#how-to-use
• OpenAI Developer Community report with OpenAI Support confirmation that app integrations are not currently supported in GPT-5.5 Pro: https://community.openai.com/t/chatgpt-app-added-via-is-recognized-by-instant-thinking-but-gpt-5-5-pro-often-cannot-see-the-app-or-its-tools/1382714

So the practical caveat seems to be: DevSpace can work with model lanes that expose ChatGPT Apps/Developer Mode tools, but the visible app pill alone is not enough evidence that the selected model runtime actually received callable tools. For now, GPT-5.5 Pro / Pro Extended should probably be documented as unsupported/product-gated or at least unverified until OpenAI changes this or someone captures clean timestamp-isolated MCP tool-call evidence.