Skip to content

Add create-only file tool for safer first-run ChatGPT probes #10

@aaamosh

Description

@aaamosh

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:

  1. call open_workspace first by itself;
  2. after it succeeds, convert any absolute path under the workspace root to a workspace-relative path;
  3. use create_file for new files / simple permission probes;
  4. use edit for targeted edits;
  5. 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.

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