Thanks again for building DevSpace. It is a genuinely interesting project; we are actively testing it as a ChatGPT Developer Mode -> local coding workspace bridge on Linux.
We hit a ChatGPT safety/permission edge case that seems separate from the OAuth persistence and Always Allow issues.
Scenario
- Package:
@waishnav/devspace@1.0.1
- Client: ChatGPT web Developer Mode app
- User prompt shape: open a workspace, then create a small probe file with exact content
In our test, ChatGPT successfully called open_workspace, but then refused to continue because the next available file-creation path was the existing write tool. From ChatGPT's point of view, that tool can overwrite existing content, so the write step was treated as destructive and the model stopped instead of creating the new file.
That behavior is understandable, but it makes simple first-run permission probes look scarier than they need to be.
Suggestion
Add a create-only file tool, for example create_file, with semantics like:
- requires
workspaceId from open_workspace
- requires a workspace-relative path
- writes with exclusive create behavior (
wx / fail if the file already exists)
- returns an error on existing files and tells the model to use
edit for targeted changes or write only when overwrite is explicitly intended
- annotations:
readOnlyHint: false, destructiveHint: false, idempotentHint: false, openWorldHint: false
Then keep the existing overwrite-capable write tool marked destructive. That part is important; the goal is not to make overwrite writes look safe, just to give ChatGPT a genuinely non-destructive new-file path.
It also helped to update the server/app instructions so the model understands the safe sequence:
- call
open_workspace first by itself;
- after it succeeds, convert any absolute path under the workspace root to a workspace-relative path;
- use
create_file for new files / simple permission probes;
- use
edit for targeted edits;
- use
write only for explicit full overwrite/rewrite requests.
Local test result
We tested a local patch with this shape:
- ChatGPT app metadata refreshed and showed
create_file as WRITE without DESTRUCTIVE.
write remained WRITE DESTRUCTIVE.
- A fresh ChatGPT chat with the DevSpace app selected ran the previously blocked prompt successfully:
open_workspace followed by create_file.
- The probe file content was correct, then we removed it after verification.
One model-routing caveat from our setup: ChatGPT Medium exposed and executed the DevSpace tools. Pro Extended showed the app pill, but did not expose actual DevSpace/api tools during that smoke test, so I would verify actual MCP calls before claiming any model-specific behavior.
I currently have this as a local patch against the installed package. If useful, I can adapt it into a PR against src/server.ts after the current OAuth/client-persistence work settles.
Thanks again for building DevSpace. It is a genuinely interesting project; we are actively testing it as a ChatGPT Developer Mode -> local coding workspace bridge on Linux.
We hit a ChatGPT safety/permission edge case that seems separate from the OAuth persistence and Always Allow issues.
Scenario
@waishnav/devspace@1.0.1In our test, ChatGPT successfully called
open_workspace, but then refused to continue because the next available file-creation path was the existingwritetool. From ChatGPT's point of view, that tool can overwrite existing content, so the write step was treated as destructive and the model stopped instead of creating the new file.That behavior is understandable, but it makes simple first-run permission probes look scarier than they need to be.
Suggestion
Add a create-only file tool, for example
create_file, with semantics like:workspaceIdfromopen_workspacewx/ fail if the file already exists)editfor targeted changes orwriteonly when overwrite is explicitly intendedreadOnlyHint: false,destructiveHint: false,idempotentHint: false,openWorldHint: falseThen keep the existing overwrite-capable
writetool marked destructive. That part is important; the goal is not to make overwrite writes look safe, just to give ChatGPT a genuinely non-destructive new-file path.It also helped to update the server/app instructions so the model understands the safe sequence:
open_workspacefirst by itself;create_filefor new files / simple permission probes;editfor targeted edits;writeonly for explicit full overwrite/rewrite requests.Local test result
We tested a local patch with this shape:
create_fileasWRITEwithoutDESTRUCTIVE.writeremainedWRITE DESTRUCTIVE.open_workspacefollowed bycreate_file.One model-routing caveat from our setup: ChatGPT
Mediumexposed and executed the DevSpace tools.Pro Extendedshowed the app pill, but did not expose actual DevSpace/api tools during that smoke test, so I would verify actual MCP calls before claiming any model-specific behavior.I currently have this as a local patch against the installed package. If useful, I can adapt it into a PR against
src/server.tsafter the current OAuth/client-persistence work settles.