Hey, thanks for the detailed report. The “The image format is not supported” error is misleading here. It’s almost certainly not about the format, but about Cursor not being able to write or read the cached copy of the image in its internal storage. This is a known pattern on Windows.
To figure out which case you have, we need a bit more info:
Open DevTools via Help > Toggle Developer Tools, go to the Console tab, and try attaching the image again. Clear the log level filter so you see everything, including Verbose, then check if you get:
red lines with [imageUtils]
a CSP violation like img-src for a vscode-file://... URL
Share what you see here, or confirm that the console is still empty after retrying.
Check if %APPDATA% or the Roaming folder is being redirected to a network drive by a corporate policy. Open %APPDATA% in File Explorer and see if it’s a UNC path like \\server\....
Quick workaround to test. Launch Cursor with a local user data directory, for example:
cursor --user-data-dir C:\CursorLocalTest
and try attaching an image there. If it works in this mode, the issue is the storage path.
Let me know the results and we can narrow down the exact cause.
Result: No [imageUtils] errors, no CSP/img-src / vscode-file:// violations.
Console only shows unrelated logs, e.g.:
[background_composer] Refreshing background composers {arch: ‘x64’, platform: ‘win32’, channel: ‘stable’, client_version: ‘3.8.23’, layout: ‘unifiedAgent’, …}
[background_composer] No repo URL, not refreshing background composers
Test 2 — APPDATA:
\\a\folderredirect$\aa\AppData\Roaming
UNC/network path — corporate Folder Redirection (not local C:\).
Test 3 — --user-data-dir workaround:
Launched from PowerShell:
Stop-Process -Name Cursor -Force -ErrorAction SilentlyContinue
& “$env:LOCALAPPDATA\Programs\cursor\Cursor.exe” --user-data-dir C:\CursorLocalTest
Result: SAME ERROR — “Failed to add image. The image format is not supported.”
Also tried with explicit TEMP (8.3 path issue):
$env:TEMP=“C:\Users\a\AppData\Local\Temp”
$env:TMP=$env:TEMP
& “$env:LOCALAPPDATA\Programs\cursor\Cursor.exe” --user-data-dir C:\CursorLocalTest
Result: STILL SAME ERROR.
Environment notes:
%TEMP% normally: C:\Users\a\AppData\Local\Temp (8.3 short path)
Local test file: C:\temp\test.jpg (valid JPEG from Paint)
Models tried: Auto, Claude Sonnet 4, GPT — all fail
Request ID: f9a7046a-279b-47e5-ab48-6e8dc12daba1
Cursor 3.8.23, Windows 10.0.26200
Conclusion: Not fixed by local user-data-dir or corrected TEMP. Console empty for image pipeline errors. Issue appears deeper than AppData storage path alone.
Thanks for the detailed tests, they help a lot. There’s an interesting detail here: a clean console log with no [imageUtils] and no CSP violation, plus the fact that --user-data-dir didn’t help, is different from the usual UNC/CSP case. In the typical UNC/CSP case, the console clearly shows a block on vscode-file://..., and using a local user data dir fixes it.
The most likely explanation is that the --user-data-dir flag didn’t actually apply because Cursor may have reused an already running instance. Let’s verify:
Fully close Cursor and make sure no processes are running:
In that window, the profile should be fresh with no settings, extensions, or chat history. Can you confirm: does it look like a clean install, or do your settings and extensions still show up? If your settings are still there, the flag didn’t take effect, and that would explain why the workaround didn’t work.
In that fresh instance, open DevTools using Help > Toggle Developer Tools > Console, try attaching an image again, and check whether [imageUtils] or any CSP violation for vscode-file:// appears.
Also, if you can, please share logs from the test run: Help > Open Logs Folder, then the files main.log and renderer*.log.
Let me know what you find, and we’ll be able to tell if this is the UNC/CSP case or something else.