workers new leaves an orphaned scaffold when config.toml can't be written

[mandar1045]

Affected area

Other

Supabase CLI version

2.117.0

Operating system

Arch Linux

Installation method

npm

Command

supabase experimental workers new api --runtime node --size 2gb --exposure private

Actual output

hen supabase/config.toml is read-only, the command fails with:
`PermissionDenied: FileSystem.writeFile (.../supabase/config.toml)`

But it still creates supabase/workers/api/. Retrying after fixing permissions fails because the directory already exists.

Expected behavior

On a config write failure, the command should not leave the scaffold directory behind, or should roll it back.

Steps to reproduce

1. Create an empty project with supabase/config.toml.
2. Make config.toml read-only: chmod 444 supabase/config.toml.
3. Run the command above.
4. Notice supabase/workers/api/ was created despite the failure.
5. Restore write permission and retry; it fails because the directory is non-empty.

Crash report ID

No response

Docker and service versions

Additional context

This makes a failed scaffold require manual cleanup before retrying.

[mandar1045]

commenting for assignment

[mandar1045]

I’ll fix it by adding rollback logic. If config.toml cannot be updated after the worker files are created, the CLI will remove the newly created worker directory before returning the error. This keeps the project clean and lets the user rerun the command without manual cleanup.