fix(mountsync): preserve local files when the server denies the write

[khaliqgant]

Problem

relayfile-mount silently destroys local files in its --local-dir whenever the workspace server rejects the push with HTTP 403. Downstream impact observed in a live cloud orchestrator sandbox:

• Workflow agents write deliverables (e.g. intro-<cli>.md, opencode.json) to /project.
• Mount's next sync cycle (~1s default) attempts to push them → server returns 403 because the synced agent lacks write permission on the workspace ACL.
• pushSingleFile at internal/mountsync/syncer.go:622-630 deletes the local file on 403 and removes it from sync state.
• From the agent's perspective the file is gone. Workflow verifications like file_exists: intro-*.md fail even though the agent successfully wrote the file moments earlier.

Evidence from a reproducing run

```

/project/.relay/permissions-denied.log

[2026-04-20T09:16:30Z] WRITE_DENIED /opencode.json: agent does not have write permission
[2026-04-20T09:16:30Z] WRITE_DENIED /probe-project-1776676590.md: agent does not have write permission
...
```

Within 5 seconds of a deterministic shell step writing /project/probe-project-*.md, /project/.probe-stamp, and /project/opencode.json, all three were gone from disk. Files written to `$HOME` (outside the mount) survived. The mount is actively, aggressively destroying user data.

Fix

On 403 during a create (exists=false), keep the local file, record a `WriteDenied` + `DeniedHash` entry in the sync state, and short-circuit future push attempts for the same content.

```diff
var httpErr *HTTPError
if errors.As(err, &httpErr) && httpErr.StatusCode == http.StatusForbidden {
if !exists {

•    s.logDenial(\"WRITE_DENIED\", remotePath, \"agent does not have write permission\")
  

•    if removeErr := os.Remove(localPath); removeErr != nil && !errors.Is(removeErr, os.ErrNotExist) {
  

•        return removeErr
  

•    }
  

•    delete(s.state.Files, remotePath)
  

•    return nil
  

•    s.logDenial(\"WRITE_DENIED\", remotePath, \"agent does not have write permission; local copy preserved\")
  

•    s.state.Files[remotePath] = trackedFile{
  

•        ContentType: snapshot.ContentType,
  

•        Hash:        snapshot.Hash,
  

•        WriteDenied: true,
  

•        DeniedHash:  snapshot.Hash,
  

•    }
  

•    return nil
  

  }
  ```

Supporting changes

• trackedFile gains `WriteDenied bool` and `DeniedHash string`. Distinct from the existing `Denied` (read-denied, local file removed) so future readers don't conflate semantics.
• pushLocal (first loop) skips re-pushing a write-denied entry when `tracked.DeniedHash == snapshot.Hash`. Prevents log spam and redundant 403 round-trips.
• pushLocal (second loop) excludes `WriteDenied` entries from the "state has it, remote doesn't → delete" reconcile path. Write-denied files were never on the remote; their absence is expected.
• applyRemoteDelete returns early for `WriteDenied` entries for the same reason.
• pushSingleFile revision selection: when re-trying a previously write-denied entry whose `Revision` is empty, fall back to the create-if-absent sentinel "0" instead of sending an empty revision.

Behavior after the fix

Scenario	Before	After
Agent writes new file, server 403s	File deleted within 1s	File preserved; state flags it WriteDenied
Same cycle, repeated	Same as above	Re-push skipped, no new denial log entry
User edits file	N/A (gone)	Hash differs from DeniedHash → retry; success or fresh denial log entry
Full reconcile / Reconcile()	Would also delete file	Excluded from delete path

Tests

• New: `TestLocalCreatePreservedWhenServerDeniesWrite` — exercises all four invariants above against a mock server that 403s every write to a specific path.
• Full mountsync suite passes (`go test ./internal/mountsync/...`).
• Full repo: `go test ./...` green.

Follow-up (not in this PR)

The 403 itself is a server-side ACL decision. This PR makes the mount non-destructive when it happens — it does not change the ACL policy. If the orchestrator agent is expected to write back, the workspace ACL for that agent needs `fs:write` on the paths it pushes. That's a relayauth/relayfile ACL concern, tracked separately.

🤖 Generated with Claude Code

---

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: ba985907e1

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Record a deletable revision for write-denied creates

This new state entry stores a write-denied file without any Revision, but pushSingleDelete later sends tracked.Revision as If-Match when the user removes/renames that local file. With an empty revision, the HTTP API returns 412 precondition_failed (handleDeleteFile rejects empty If-Match), so local delete events start failing and the stale write-denied record is never cleaned up. In practice, a file that was denied on create can become undeletable from sync state and future recreates on that path can behave incorrectly.

Useful? React with 👍 / 👎.

[devin-ai-integration]

✅ Devin Review: No Issues Found

Devin Review analyzed this PR and found no bugs or issues to report.