On macOS, Remote Control’s private worker registers then immediately crashes when the workspace root contains CJK characters. The UI shows: “Selected private worker is not available. It may have disconnected.” / ERROR_BAD_REQUEST / ConnectError [invalid_argument].
Worker log: Error starting exec-daemon: Cannot convert argument to a ByteString because the character at index 27 has a value of 21518 which is greater than 255. Then: Worker exited (code=1).
21518 is U+540E (后). Workspace was …/AICode/后端. Local Agent in the same folder works. Only the private worker dies because the path is put into a ByteString/HTTP header (code points must be 0–255).
Steps to Reproduce
Open a macOS workspace whose root path contains Chinese characters (example: …/AICode/后端).
Enable Remote Control, or start a Cloud/Background Agent targeted at this Mac.
Send any message.
Worker log shows the ByteString error and exits code=1. UI shows private worker unavailable.
Expected Behavior
Remote Control should accept Unicode/CJK workspace paths (UTF-8 JSON, percent-encoding, or RFC 5987), not raw ByteString headers. Japanese/Korean/emoji paths with code points > 255 would hit the same crash.
Hey @666ofmine
A workspace path with non-Latin characters (Chinese, Japanese, Korean, emoji, etc.) stops the Remote Control private worker from registering, so it exits before connecting. Regular local agents don’t hit that path, which is why they work in the same folder.
Your workaround is the right one: open an ASCII-only parent like …/AICode and it’ll connect normally.
Not intended behavior, and nothing on your end. We’ve let the team know and it’s an issue we’re tracking. I’ll post here when there’s an update.
Still reproducible on Cursor 3.22.7 with a Japanese (CJK) workspace path.
UI error:
“Selected private worker is not available. It may have disconnected.”
Request ID: 074304bf-3f7c-45f4-a439-d1f6c42ae2da
Environment:
Cursor 3.22.7 (macOS)
macOS 26.7 (25G229), arm64
Workspace path pattern:
/Users//Dropbox//git//…
(path contains Japanese characters; e.g. code point U+30B5 at the failing index)
Worker log (anysphere.cursor-agent-worker):
Invalid bridge registration headers
error=TypeError: Cannot convert argument to a ByteString because the character at index 20 has a value of 12469 which is greater than 255.
12469 is U+30B5 (katakana). Header list includes x-working-directory.
Local Agent works in the same folder; only Remote Control / This Mac private worker fails.
Symlink from an ASCII path does not help — the worker resolves realpath and still crashes.
Please fix non-ASCII workspace path encoding for bridge registration headers.
@AKI_MIZU that confirms it’s still reproducing on 3.22.7 with a Japanese path. Same cause as the original: the worker sends the workspace path in a header that only allows Latin-1 characters, so any Japanese, Chinese, Korean, or emoji folder name stops it from registering. It’s on our side and we’re tracking it.
The workaround for now is to open the workspace from an ASCII-only path. As you found, a symlink won’t help because the worker resolves the real path, so the actual folder on disk needs to be ASCII (for example move or clone the repo under ~/git/project with no non-Latin characters in the full path). Local Agent is unaffected in the same folder.