I've been seeing DevSpace drop out fairly often during longer ChatGPT tasks. I spent some time narrowing it down and found two separate problems that seem to be getting mixed together.
1. The yield parameter name is being changed before it reaches DevSpace
DevSpace 1.0.8 registers the yield option as a camelCase key: yield followed immediately by TimeMs (no hyphen). ProcessSessionManager reads that same camelCase field and falls back to 10 seconds when it isn't provided.
In the tool schema exposed to GPT-5.6 Sol, the key instead contains a hyphen after yield (yield-timeMs). That means the value ChatGPT sends isn't the field DevSpace is looking for.
I tested the installed ProcessSessionManager directly with the same ~11 second command, changing only the key:
camelCase key, 30000
-> finished in 11.53s
-> running=false, exitCode=0
hyphenated key, 30000
-> returned after 10.02s
-> running=true
The second result lines up exactly with DevSpace's 10 second default.
I also tried a small compatibility shim that accepts the hyphenated key and maps it to DevSpace's camelCase field. Through ChatGPT, the behavior changed immediately:
Sleep 20s, yield=0
-> session returned in ~25ms instead of ~10s
Sleep 15s, yield=30000
-> successful runs returned after ~15.2s with exitCode=0
So this part looks like a real schema/argument-name mismatch rather than a timing issue inside ProcessSessionManager.
2. There is also a separate intermittent MCP disconnect
Fixing the yield-key mismatch did not stop the connection failures.
With the compatibility shim in place, I ran six 15-second calls:
1: mcp_network_error
2: success (15.204s)
3: mcp_network_error
4: success (15.221s)
5: success (15.213s)
6: success (15.204s)
This doesn't seem to be a simple long-request timeout. Against the normal 1.0.8 instance I also ran ten near-instant echo calls: the first two failed with mcp_network_error, then the next eight all succeeded in about 25-27ms. In practice it feels more like the MCP connection/session enters a bad window for a while and then recovers.
The local process itself survives these disconnects. I ran a five-minute heartbeat command that printed one line every five seconds. Several polling calls failed with mcp_network_error, but after reconnecting I could continue polling the same process session and eventually got all 60 heartbeats plus exitCode=0. The DevSpace server stayed on the same PID throughout.
I also did a basic reachability check during the same testing period. These were unauthenticated requests where the expected HTTP 401 was used only as proof that the endpoint was reachable:
127.0.0.1:7676/mcp
120/120 reachable
avg 1.4ms, max 2.2ms
public Tailscale Funnel /mcp
120/120 reachable
avg 41.2ms, p95 23.2ms, max 2701ms
0 connection failures
That doesn't rule out a path-specific problem between OpenAI and the Funnel, but it makes a local DevSpace crash or the Funnel simply being down look unlikely.
One other thing I noticed: while reproducing the failures, DevSpace logs showed repeated mcp_session_created events from openai-mcp/1.0.0 as ChatGPT reconnected. DevSpace 1.0.8 keeps MCP sessions in memory with a 24-hour idle timeout and a 5-minute cleanup sweep. I haven't shown that session accumulation is the cause, but the session churn may be useful when debugging this.
Environment
- Windows 11 Pro 23H2 (build 22631)
- DevSpace 1.0.8 (current npm
latest)
- Node v24.12.0
- Tailscale 1.102.3, Funnel ->
http://127.0.0.1:7676
- ChatGPT web, GPT-5.6 Sol
- MCP user-agent in DevSpace logs:
openai-mcp/1.0.0
Related issues
I've been seeing DevSpace drop out fairly often during longer ChatGPT tasks. I spent some time narrowing it down and found two separate problems that seem to be getting mixed together.
1. The yield parameter name is being changed before it reaches DevSpace
DevSpace 1.0.8 registers the yield option as a camelCase key:
yieldfollowed immediately byTimeMs(no hyphen).ProcessSessionManagerreads that same camelCase field and falls back to 10 seconds when it isn't provided.In the tool schema exposed to GPT-5.6 Sol, the key instead contains a hyphen after
yield(yield-timeMs). That means the value ChatGPT sends isn't the field DevSpace is looking for.I tested the installed
ProcessSessionManagerdirectly with the same ~11 second command, changing only the key:The second result lines up exactly with DevSpace's 10 second default.
I also tried a small compatibility shim that accepts the hyphenated key and maps it to DevSpace's camelCase field. Through ChatGPT, the behavior changed immediately:
So this part looks like a real schema/argument-name mismatch rather than a timing issue inside
ProcessSessionManager.2. There is also a separate intermittent MCP disconnect
Fixing the yield-key mismatch did not stop the connection failures.
With the compatibility shim in place, I ran six 15-second calls:
This doesn't seem to be a simple long-request timeout. Against the normal 1.0.8 instance I also ran ten near-instant
echocalls: the first two failed withmcp_network_error, then the next eight all succeeded in about 25-27ms. In practice it feels more like the MCP connection/session enters a bad window for a while and then recovers.The local process itself survives these disconnects. I ran a five-minute heartbeat command that printed one line every five seconds. Several polling calls failed with
mcp_network_error, but after reconnecting I could continue polling the same process session and eventually got all 60 heartbeats plusexitCode=0. The DevSpace server stayed on the same PID throughout.I also did a basic reachability check during the same testing period. These were unauthenticated requests where the expected HTTP 401 was used only as proof that the endpoint was reachable:
That doesn't rule out a path-specific problem between OpenAI and the Funnel, but it makes a local DevSpace crash or the Funnel simply being down look unlikely.
One other thing I noticed: while reproducing the failures, DevSpace logs showed repeated
mcp_session_createdevents fromopenai-mcp/1.0.0as ChatGPT reconnected. DevSpace 1.0.8 keeps MCP sessions in memory with a 24-hour idle timeout and a 5-minute cleanup sweep. I haven't shown that session accumulation is the cause, but the session churn may be useful when debugging this.Environment
latest)http://127.0.0.1:7676openai-mcp/1.0.0Related issues