[BUG] Cowork silently corrupts files in OneDrive folders with Files-On-Demand

[tlrichar]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

Bug report: Cowork silently corrupts files in OneDrive folders with Files-On-Demand

Summary

When a Cowork session has access to a folder that lives in a OneDrive (or any cloud-sync) directory with Files-On-Demand enabled, Cowork's file tools (Read, Edit, Write, and the Linux mount that powers bash) operate on the local placeholder/stub of a file rather than the actual cloud-hydrated content. When Cowork then writes to the file (thinking it has the canonical version), it silently overwrites the user's full cloud copy with the truncated stub plus whatever edits Cowork made. The user loses data silently. No error, no warning, no diff prompt.

Reproduction

1. Create a file in a OneDrive folder (e.g., C:\Users\me\OneDrive\Documents\Projects\big-file.md) that is >100 KB and has been synced to cloud but evicted from local cache (the "cloud-only" green-circle icon, or any Files-On-Demand state where the file isn't fully kept on disk).
2. Connect that folder to Cowork.
3. Have Cowork read or edit the file. From Cowork's perspective, the file appears to be ~130 KB (the typical placeholder size, regardless of true content size). All sections past that byte boundary appear truncated/missing.
4. Have Cowork write to the file (e.g., via Edit, Write, or cp over the mount).
5. Result: the actual file on disk is now the truncated content Cowork saw, plus Cowork's edits. The user's full canonical content is destroyed unless OneDrive's version history can be used to roll back.

Evidence from this session

Files destroyed or corrupted by this pattern in one session:

File | Real size (user view) | What Cowork saw | What got written back -- | -- | -- | -- 04-decisions.md | ~158 KB (51 ADRs) | ~114 KB (truncated mid-ADR-040, ADRs 041–045 missing) | If we'd written, would have lost ADRs 041–045. Recovered by reconstructing the lost ADRs from cross-references in other docs. 14-ui-mockups.html | ~258 KB (15 sections) | ~24 KB (only sections 1 + start of 2) | Cowork "rebuilt" sections 3–15 with a different (worse) design language. User had to restore from OneDrive version history. 10-runtime-design.md | ~194 KB (full §1–§10) | ~137 KB (truncated mid-§5.13, missing §5.14–§5.19 + §6–§10) | Multiple times. Eventually resolved by user uploading canonical via chat. Multiple SVG diagrams | ~30 KB | ~30 KB but truncated mid-tag | Render failures (cairosvg couldn't parse); each required patch-via-/tmp workaround.

The unifying signal that distinguishes a real file from a Files-On-Demand placeholder:

bash

$ stat 10-runtime-design.md
  Size: 137377   Blocks: 0       IO Block: 262144 regular file
                        ^^^^^^^^^
                        ZERO BLOCKS on disk despite non-zero Size

Blocks: 0 (or any value much smaller than Size / 4096) is the giveaway. The Windows attribute is FILE_ATTRIBUTE_RECALL_ON_OPEN / FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS.

Suggested mitigations (in order of impact)

1. Detect Files-On-Demand placeholders before reading. On every file Read from a OneDrive/iCloud/Google Drive folder, check stat for Blocks == 0 && Size > 0. If detected, either (a) force hydration by reading via a Windows API call that resolves the placeholder (the standard Win32 CreateFile/ReadFile does this automatically when called from a non-FILE_FLAG_OPEN_NO_RECALL context), or (b) error out and surface to the user: "This file is currently cloud-only. Click to download for editing, then retry."
2. Refuse to write to a file that looks dramatically smaller than the version Cowork last saw. A simple guard: if a write is about to replace a file whose previous size was >2× larger, require an explicit confirmation or skip. This single check would have prevented every data-loss incident in this session.
3. Warn prominently in the docs / agent system prompt. Even just adding to the system prompt "Cloud-sync folders (OneDrive, iCloud, Google Drive) with Files-On-Demand can serve truncated placeholder files; verify with stat ... Blocks before treating large files as canonical" would let agents detect and route around the problem.
4. Use the OneDrive / iCloud / Google Drive API directly when available. For OneDrive folders, Microsoft Graph API can read the cloud copy regardless of local state. Cowork could detect a OneDrive path and use Graph instead of the local mount for files >N KB.
5. For the Linux mount specifically: force-hydrate every file in the connected folder on session start, or document clearly that the mount is "best-effort over Files-On-Demand" and provide a fallback path.

Workaround we used (which should not be the user's job)

For every doc edit in this session past the first incident:

1. User drags the file into chat (uploads to Cowork's /uploads/ folder, which is in AppData — outside OneDrive, no Files-On-Demand layer).
2. Cowork reads from /uploads/, edits a copy in /outputs/ (also AppData).
3. User manually opens both files in their editor, copies the patched version, pastes over the OneDrive original.
4. Cowork verifies indirectly (file size in Windows Explorer matches Cowork's patched-file size).

This is six manual steps per edit on what should be a single-tool-call operation. The user effectively had to operate two file systems and broker between them. They (rightly) called this out as a Cowork-team-should-fix-it problem.

Severity

High. The default Windows + OneDrive configuration (Files-On-Demand on, the default since Windows 10 1709) is the trigger. Anyone using Cowork against a OneDrive project folder is at risk of silent data loss on any large file the agent edits. The user has no way to know it happened until they notice the missing content later.

What Should Happen?

Files should sync from onedrive to shared drive without issue.

Error Messages/Logs

Steps to Reproduce

see original message above

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

No response

Claude Code Version

Claude 1.8555.2 (a476c3) 2026-05-22T23:04:37.000Z

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

No response

[github-actions]

Found 3 possible duplicate issues:

1. [BUG] Cowork cannot read Drive Desktop placeholder files; failed reads burn tokens on retries #55627
2. [BUG] Cowork: virtiofs FUSE mount serves truncated/stale files — host-side file changes not reflected in VM #38993
3. [BUG] EEXIST: mkdir 'session-env/<UUID>' when .claude is a symlink to OneDrive-synced folder (Windows) #50886

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[tlrichar]

These don't seem to be related to the same problem I'm seeing. #2 looks somewhat similar, but this is definitely related to OneDrive, as we can copy the files to an unwatched directory and not have this problem.

[jshaofa-ui]

Proposed Solution

Solution: claude-code #62140 — Cowork OneDrive Files-On-Demand Silent Data Corruption

Issue Summary

• Repo: anthropics/claude-code
• Issue: #62140
• Title: Cowork silently corrupts files in OneDrive folders with Files-On-Demand
• Labels: bug, data-loss, platform:windows, area:tools, area:cowork
• Severity: P0 — Silent data loss, no warning, no diff prompt
• Competition: Zero (only bot duplicate-detection + author response)
• Price: $3,000–$5,000

---

Root Cause Analysis

The Files-On-Demand Problem

Windows OneDrive/iCloud/Google Drive with Files-On-Demand enabled stores "placeholder stub" files on disk. These files:

• Report a non-zero Size in stat (the cloud file size)
• Report Blocks: 0 (no actual data blocks allocated on disk)
• Have the FILE_ATTRIBUTE_RECALL_ON_OPEN / FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS Windows attributes
• When read through the Linux mount layer (WSL2 drvfs, 9P), the placeholder content is returned instead of triggering hydration

The Data Loss Chain

1. User has a project folder in OneDrive with Files-On-Demand (default on Windows 10+)
2. Cowork mounts the folder via Linux mount (WSL2 drvfs or similar)
3. Cowork's file tools (Read, Edit, Write) operate on the mount
4. When reading a cloud-only file, the mount returns the ~130KB placeholder stub, not the full file
5. Cowork edits the stub content, believing it has the canonical version
6. Cowork writes back the edited stub, destroying the full cloud copy
7. No error, no warning, no diff prompt — silent data loss

Evidence from the Issue

File	Real size	What Cowork saw	What got written
04-decisions.md	~158 KB (51 ADRs)	~114 KB (truncated mid-ADR-040)	Would have lost ADRs 041–045
14-ui-mockups.html	~258 KB (15 sections)	~24 KB (sections 1 + start of 2)	Cowork "rebuilt" sections 3–15 with worse design
10-runtime-design.md	~194 KB (full §1–§10)	~137 KB (truncated mid-§5.13)	Multiple times
Multiple SVG diagrams	~30 KB	~30 KB but truncated mid-tag	Render failures

Detection Signal

$ stat 10-runtime-design.md
  Size: 137377   Blocks: 0       IO Block: 262144 regular file
                        ^^^^^^^^^
                        ZERO BLOCKS on disk despite non-zero Size

Blocks == 0 && Size > 0 is the definitive signal of a Files-On-Demand placeholder.

---

Fix Approach (5-Layer Defense)

Layer 1: Pre-Read Placeholder Detection (Critical)

File: src/tools/file/read.ts (or equivalent file read tool)

Before every file read operation, detect placeholders and force hydration:

import { statSync, readFileSync } from 'fs';
import { platform } from 'os';
import { execSync } from 'child_process';

interface FileReadResult {
  content: string;
  warning?: string;
  hydrated?: boolean;
}

function isPlaceholderFile(filePath: string): boolean {
  if (platform() !== 'win32') return false;
  
  try {
    const st = statSync(filePath);
    // Placeholder: non-zero size but zero allocated blocks
    if (st.size > 0 && (st as any).blocks === 0) {
      return true;
    }
    // Also check Windows file attributes via wslvar
    const wslPath = windowsToWslPath(filePath);
    const wslStat = execSync(`stat -c "%b" "${wslPath}" 2>/dev/null`).toString().trim();
    const wslSize = execSync(`stat -c "%s" "${wslPath}" 2>/dev/null`).toString().trim();
    if (parseInt(wslSize) > 0 && parseInt(wslStat) === 0) {
      return true;
    }
  } catch {
    // File doesn't exist or can't be stat'd — let the read fail naturally
  }
  return false;
}

function forceHydrateFile(filePath: string): void {
  // Method 1: Use PowerShell to trigger OneDrive hydration
  if (platform() === 'win32') {
    try {
      execSync(
        `powershell -Command "Add-Type -Name FileUtil -MemberDefinition '[DllImport(\"kernel32.dll\")] public static extern bool SetFileAttributes(string lpFileName, uint dwFileAttributes);' -PassThru; [FileUtil]::SetFileAttributes('${filePath}', 0x00000004)"`,
        { timeout: 10000 }
      );
    } catch {
      // Fallback: use fsync to trigger recall
    }
  }
  
  // Method 2: Open with CreateFile (no FILE_FLAG_OPEN_NO_RECALL)
  // This is the default behavior — just reading the file triggers hydration
  // The issue is the Linux mount layer bypassing this
  const fd = openSync(filePath, constants.O_RDONLY);
  // Read at least 1 byte to trigger the recall
  const buf = Buffer.alloc(1);
  readSync(fd, buf, 0, 1, 0);
  closeSync(fd);
}

function readFileWithPlaceholderGuard(filePath: string): FileReadResult {
  if (isPlaceholderFile(filePath)) {
    forceHydrateFile(filePath);
    // Verify hydration succeeded
    if (isPlaceholderFile(filePath)) {
      return {
        content: '',
        warning: `File "${filePath}" is a cloud-only placeholder and could not be hydrated. ` +
          `Please ensure the file is downloaded locally before editing, or copy it to a non-synced directory.`,
        hydrated: false
      };
    }
    return {
      content: readFileSync(filePath, 'utf-8'),
      warning: `File "${filePath}" was a cloud-only placeholder and has been hydrated.`,
      hydrated: true
    };
  }
  return { content: readFileSync(filePath, 'utf-8') };
}

Layer 2: Write Size Guard (Data Loss Prevention)

File: src/tools/file/write.ts (or equivalent file write tool)

Prevent writes that would dramatically shrink a file:

const SIZE_RATIO_THRESHOLD = 2.0; // Warn if new content is <50% of original size
const MAX_SILENT_SHRINK = 1024;   // Bytes — allow small truncations (trailing newline etc.)

interface WriteGuardResult {
  allowed: boolean;
  reason?: string;
  originalSize: number;
  newSize: number;
}

function checkWriteGuard(
  filePath: string,
  newContent: string,
  previousKnownSize?: number
): WriteGuardResult {
  try {
    const st = statSync(filePath);
    const originalSize = previousKnownSize ?? st.size;
    const newSize = Buffer.byteLength(newContent, 'utf-8');
    
    // Allow if file is small or shrink is minimal
    if (originalSize < MAX_SILENT_SHRINK) {
      return { allowed: true, originalSize, newSize };
    }
    
    const ratio = newSize / originalSize;
    if (ratio < 1 / SIZE_RATIO_THRESHOLD) {
      return {
        allowed: false,
        reason: `Write would reduce file from ${originalSize} bytes to ${newSize} bytes ` +
          `(${Math.round(ratio * 100)}% of original). This may indicate a truncated read ` +
          `(e.g., cloud-sync placeholder). Please verify the file content is complete ` +
          `before writing, or confirm this truncation is intentional.`,
        originalSize,
        newSize
      };
    }
    return { allowed: true, originalSize, newSize };
  } catch {
    // File doesn't exist — this is a new file, allow
    return { allowed: true, originalSize: 0, newSize: Buffer.byteLength(newContent, 'utf-8') };
  }
}

Layer 3: System Prompt Warning

Add to the Cowork system prompt:

IMPORTANT: When working with files in cloud-synced folders (OneDrive, iCloud, Google Drive),
the file may be a "placeholder" that appears smaller than the actual cloud content.
Before reading or editing any file >10KB in a synced folder:
1. Run `stat <file>` and check that "Blocks" is non-zero (or Size/Blocks ratio is reasonable)
2. If Blocks==0 and Size>0, the file is cloud-only — DO NOT edit it directly
3. Instead, copy it to a local directory first, edit there, then copy back
4. Or force hydration: on Windows, opening the file in Explorer or running `type <file>` in PowerShell

Layer 4: Session-Level Placeholder Scan

On Cowork session start, scan the connected folder for placeholders:

async function scanForPlaceholders(rootDir: string): Promise<string[]> {
  const placeholders: string[] = [];
  
  async function scan(dir: string) {
    const entries = await readdir(dir, { withFileTypes: true });
    for (const entry of entries) {
      const fullPath = join(dir, entry.name);
      if (entry.isDirectory()) {
        // Skip .git, node_modules, etc.
        if (['.git', 'node_modules', '.DS_Store'].includes(entry.name)) continue;
        await scan(fullPath);
      } else if (entry.isFile()) {
        try {
          const st = statSync(fullPath);
          if (st.size > 1024 && (st as any).blocks === 0) {
            placeholders.push(fullPath);
          }
        } catch {
          // Skip inaccessible files
        }
      }
    }
  }
  
  await scan(rootDir);
  return placeholders;
}

Layer 5: Linux Mount Force-Hydration

For the Linux mount layer (WSL2 drvfs), force-hydrate all files in the connected folder on session start:

# In the mount setup script, before exposing files to Cowork:
# Force hydration of all OneDrive/iCloud placeholders
find "$MOUNT_ROOT" -type f -size +1k -exec sh -c '
  blocks=$(stat -c "%b" "$1" 2>/dev/null)
  size=$(stat -c "%s" "$1" 2>/dev/null)
  if [ "$size" -gt 0 ] && [ "$blocks" -eq 0 ]; then
    # Trigger hydration by reading first byte
    dd if="$1" of=/dev/null bs=1 count=1 2>/dev/null
  fi
' _ {} \;

---

Testing Plan

Unit Tests

1. Placeholder detection: Mock stat to return blocks=0, size=137377 — verify isPlaceholderFile() returns true
2. Hydration trigger: Verify forceHydrateFile() changes blocks from 0 to non-zero
3. Write guard: Test with original=194KB, new=137KB — verify rejection
4. Write guard edge case: Test with original=100 bytes, new=50 bytes — verify allowance (small file)

Integration Tests

1. OneDrive folder simulation: Create a file with blocks=0 using truncate + chattr on Linux
2. Full read-edit-write cycle: Verify placeholder detection → hydration → correct edit → safe write
3. Cross-platform: Test on Windows + WSL2, macOS + iCloud, Linux + Google Drive

E2E Tests

1. Cowork session with OneDrive folder: Connect Cowork to a OneDrive folder with cloud-only files
2. Verify no data loss: After Cowork edits, compare file content with cloud version
3. Stress test: 50 files of varying sizes in OneDrive, Cowork edits all — verify zero corruption

---

Impact Assessment

• User impact: HIGH — Any Cowork user with OneDrive/iCloud/Google Drive synced folders is at risk
• Data loss severity: CRITICAL — Silent, no warning, no recovery without version history
• Fix complexity: MODERATE — 5-layer approach, each layer is independently deployable
• Risk of fix: LOW — Detection is read-only, write guard is conservative, hydration is standard Windows API
• Rollout strategy:
  1. Deploy Layer 2 (write guard) immediately — zero risk, prevents all data loss
  2. Deploy Layer 1 (placeholder detection) — may slow first read of cloud files
  3. Deploy Layer 3 (system prompt) — immediate mitigation
  4. Deploy Layer 4+5 (scan + mount hydration) — session startup optimization

---

Pricing: $3,000–$5,000

• P0 data-loss bug with confirmed reproduction
• Detailed evidence table with real file corruption data
• Zero competition
• Multi-layer fix with code-level implementations
• Comprehensive testing plan
• Immediate deployability (write guard can ship independently)

[mauromelani]

Summary

On Cowork (Claude Desktop, Windows), after a file under a OneDrive-synced folder is
edited via the file tools (Read/Write/Edit, which operate on the real Windows disk),
the SAME file read from the Linux sandbox bash (via the mounted folder under
/sessions//mnt/...) is served TRUNCATED — cut mid-line, fewer lines than the
real file. The authoritative file on disk is complete. No error is raised.

This looks related to the existing OneDrive Files-On-Demand reports (#62140, #41702,
#50873, #41710, #25293), but with a key difference that narrows the root cause:
the affected files are fully hydrated AND pinned ("Always keep on this device"),
NOT dehydrated cloud stubs. So the popular "Cowork reads the dehydrated placeholder
stub" explanation does not apply here. The data is fully present locally; the mount
still serves a short view.

Environment

• OS: Windows 11 Home, build 10.0.26200.8655
• OneDrive client: 26.095.0519.0003
• OneDrive Files On-Demand: enabled (this version has no GUI toggle to disable it)
• Affected folders: working folders under C:\Users<user>\OneDrive...

Evidence (verified from Windows side)

For an affected .py file:

• Real size on disk: 205337 bytes / 4262 lines (confirmed via PowerShell Get-Content).
• File attributes: 0x80420 = ARCHIVE + REPARSE_POINT + PINNED.
  • PINNED (0x80000) = "Always keep on this device".
  • NO RECALL_ON_DATA_ACCESS (0x400000), NO RECALL_ON_OPEN (0x200000),
    NO OFFLINE (0x1000) => file is fully materialized locally, not a stub.
• Reparse tag: 0x9000601a (IO_REPARSE_TAG_CLOUD — OneDrive cldflt). Present even
  though the file is pinned and fully downloaded.
• Read via the file tools: always returns the full, correct content.
• Read via the Linux sandbox bash (mounted path): returns truncated content,
  cut at end-of-file; python -m py_compile fails with SyntaxError at the cut point.

Observed characteristics

• Truncation is always at the END of the file (clipped, not corrupt in the middle).
• It persists for the whole session; waiting 20-40s does not fix it.
• A full Windows reboot temporarily restores the complete view via the mount, but
  subsequent edits (from the Windows file tools) re-truncate it.
• Large BINARY files (.xlsx) COPIED BY the bash itself show the correct full size
  => not a total mount failure; specific to text files modified EXTERNALLY
  (Windows side) and then read through the mount.

Hypothesized root cause

Cache-coherence failure in the sandbox host-folder mount (virtiofs/Plan9) for
OneDrive cloud-reparse-point files that are modified by an external (host-side)
writer. The mount appears to cache file metadata (size) and/or content pages from
before the external edit and does not invalidate on external modification. OneDrive's
cloud filter (cldflt) reparse indirection seems to be the trigger: files copied by
the guest itself are fine; plain external writes to cloud-reparse files are not.
Because pinned+hydrated files still carry the cloud reparse tag, pinning does NOT
avoid the bug.

Repro

1. On Windows, place a multi-thousand-line text file in a OneDrive folder set to
   "Always keep on this device".
2. In Cowork, edit/grow it with the file tools (Write/Edit).
3. From the Linux sandbox bash, wc -l / cat the same file via the mounted path.
   => Observed: fewer lines than the real file; content cut mid-line at the end.
   python -m py_compile <file> => SyntaxError at the cut point.
4. Read the same file with the file tools => full, correct content.

Impact / data-loss risk

Read truncation is silent (no error). The dangerous corollary: if the sandbox writes
the file back based on the truncated view, it overwrites the complete file with a
truncated one. For users with default Windows + OneDrive (Files On-Demand on by
default), this is a real data-loss vector. See #62140 (labeled data-loss).

Suggested fixes

• Invalidate the mount's attribute/page cache on external modification of
  cloud-reparse files (or disable caching for reparse-point-backed files).
• At minimum, detect a size/Blocks mismatch between the mount view and the host
  file and surface an error instead of silently serving a short read.
• Never let a write proceed when the about-to-be-written file is dramatically
  smaller than the last-seen size, for cloud-sync folders.

Related issues

#62140, #41702, #50873, #41710, #25293

[JBinAussie]

A related but distinct failure mode: binary writes to OneDrive-on-external-drive are blocked outright, not just truncated

Landing here after #19318 was closed as a duplicate of #24964 (also closed) — that one covered the Windows "home directory only" restriction, but my case is macOS + external drive, so it doesn't quite fit either thread. This issue is the closest match, but worth flagging that what I'm hitting is a step earlier than the corruption described above: the file never gets far enough to be truncated, because it can't be written at all.

Setup

• MacBook (Apple Silicon), current macOS
• Claude Desktop, Cowork research preview
• Target folder: OneDrive-synced folder on an external SSD

Two bugs stacked together

1. The bash sandbox never mounts the external volume at all. cp inside bash, re-requesting the folder, quitting/relaunching, rebooting — all fail with "couldn't be mounted into the bash sandbox... No such file or directory." Checking the sandbox's mount table confirms only internal app folders (outputs, uploads, .auto-memory, .claude, .remote-plugins) are FUSE-bridged; the external volume is absent regardless of /Volumes/ permissions or Full Disk Access grants. This matches the "intended behaviour, looking at how to support external drives" note from @MarshallOfSound on [BUG] Cowork: Folder picker rejects folders outside home directory, symlinks/junctions also blocked #24964 — so it sounds like this is a known, accepted gap rather than something specific to me, just not yet fixed for macOS external volumes either.

2. Even once the host file tools reach the folder (by connecting the directory, which grants host-side access separately from the sandbox mount), Write is text-only. A plain-text test file writes fine — proving the folder itself is reachable — but there's no binary/base64 mode, so a generated DOCX/PDF (built inside the sandbox, since that's where the doc-generation tooling actually runs) can never be copied out to the folder. Read refuses the binary in the reverse direction too.

Net effect: binary output to this folder is blocked from both directions, with no truncation or corruption involved — it simply never lands. I'd guess the Files-On-Demand truncation described above kicks in for whoever gets past step 1 (i.e. a folder that does get mounted, or is accessed purely through the host file tools); on external+cloud-sync macOS setups you don't even get that far.

Why the usual workarounds don't apply

• Symlink into home directory → resolved and rejected by Cowork's home-directory check (same underlying restriction as [BUG] Cowork: Folder picker rejects folders outside home directory, symlinks/junctions also blocked #24964).
• SMB/NFS loopback mount → reported to fail on Apple Silicon + Sonoma+, since macOS sandboxes smbd/nfsd away from /Volumes/.
• Google Drive works fine for the same binary files, but only because it's a separate cloud API connector with base64 upload — nothing to do with the local mount. No equivalent write-capable connector exists for OneDrive/SharePoint (the installed Microsoft 365 connector is search+read only).

Suggested fixes

1. Extend the sandbox mount to include external volumes on macOS (tracked implicitly by [BUG] Cowork: Folder picker rejects folders outside home directory, symlinks/junctions also blocked #24964/[BUG] Cowork: Cannot mount folders from external volumes (/Volumes/) #19318) — fixes the root cause for this case.
2. Independent of (1): give the host Write tool a binary/base64 mode, so binaries can reach any host path the file tools already have access to. Also helps anyone who wants Cowork to drop a binary directly instead of building in outputs and dragging it over manually.
3. A write-capable Microsoft Graph connector (PUT /drive/items/{id}/content) alongside the existing read-only Microsoft 365 connector would mirror the Google Drive path and route around the mount issue for OneDrive/SharePoint specifically.

Current workaround: build the file in Cowork's own outputs folder, then manually drag it into the OneDrive folder for sync.