[Bug]: POST /api/file/save cannot create new files — existing-path resolver 404s before the write

[KevinBarrus]

Description

POST /api/file/save can never create a new file. Any save request whose target path does not already exist returns 404 File not found before the write happens. Only overwriting existing files works.

Source evidence

Audited against the 0.4.12 source preview (release/extraction.json sourceRevision 9b9885e42a3cf1a3df1cfa52a46e4fdb034cfcee); line numbers refer to that revision.

• The save route passes resolveBodyPath to the handler: packages/local-runtime/src/files/api.ts:557-559.
• resolveBodyPath calls resolveExistingWorkspacePath: packages/local-runtime/src/files/api.ts:1950-1960.
• resolveExistingWorkspacePath runs realpath(target) and maps the resulting ENOENT to a 404 File not found response: packages/local-runtime/src/files/api.ts:1997-2002.
• The handler itself clearly intends to create files: packages/local-runtime/src/files/save.ts:23-25 does mkdir(dirname(target.absolute), { recursive: true }) followed by writeFile(...) — both dead code for new files because the 404 short-circuits first.

So the mkdir + writeFile creation path is unreachable for any nonexistent target.

Expected behavior

Saving to a new path creates the file (that is what the recursive mkdir in the handler is for).

Actual behavior

Saving to a new path returns 404 {"error":"File not found"}.

Suggested fix

Give the save route a resolver that allows a non-existing leaf: resolve the parent directory with realpath, validate containment against the workspace root, then append the leaf name. resolveExistingWorkspacePath is the right resolver for read/open/reveal routes, but not for a write that is expected to create.

Environment

Found by source audit; not runtime-reproduced yet. The relevant code paths are small and self-contained, so the trace above should be quick to confirm.

[KevinBarrus]

Closing for now to keep this batch of reports smaller — I kept the two highest-impact findings open (#150 permission enforcement, #152 context compaction trigger). Happy to reopen or refile if maintainers find this one useful; the analysis in the body stays valid against the cited revision.

[KevinBarrus]

Reopening — closing them added nothing since closed issues stay fully visible. Keeping all five open for triage.

[hetaoBackend]

Thanks for the detailed source trace. The current save route does resolve the target through resolveExistingWorkspacePath before reaching mkdir/writeFile, so the new-file path described here is a valid concern in that HTTP handler.

We are keeping this separate from the current TUI/CLI fix batch: the standalone TUI uses the in-process CliService path and does not expose this HTTP front door (see docs/architecture.md). That scope distinction does not mean the handler is correct.

Could you share the product/version and user-facing action that reaches this endpoint, or a minimal invocation against the host that exposes it? A fix should cover nonexistent parent directories as well as the leaf, while preserving canonical workspace containment and symlink protections. Leaving this open pending that host-level reproduction.