Two Cloud Agent bugs. Both reproduce every time in this session.
Japanese IME cannot commit in Cloud Agent chat
Product: Cloud Agents web chat
OS: Windows, Japanese IME
What happens: I type Japanese. Candidate list appears. Confirming the candidate does not insert the word. The field stays broken (roman leftover + leftover kana). I cannot write Japanese to the agent.
On the same VM, curl and Desktop Chrome both get HTTP 200 (about 6KB HTML). The app is healthy.
Preview from the Cursor agent page never reaches the process (no request logs). Browser shows ERR_EMPTY_RESPONSE / Connection reset / -324.
Binding, HTTP/1.1 Content-Length proxy, dual-stack listen, allowedDevOrigins did not change Preview. Traffic never arrives.
Please treat these as Cursor Cloud Agent platform bugs, not app bugs.
Steps to Reproduce
Bug A — Japanese IME
Open a Cloud Agent chat in the browser.
On Windows, turn on Japanese IME.
Type Japanese and try to confirm a candidate (Enter / Space / click).
The confirmed word is not inserted. The field stays broken.
Bug B — Preview / Cloud agent view
Start a Cloud Agent that serves a web app on 127.0.0.1:43147
On the same VM, Desktop Chrome and curl both return HTTP 200.
Open Preview from the Cloud Agent page, or wait for the toast “Cloud agent view is unavailable”.
Preview shows ERR_EMPTY_RESPONSE / Connection reset / -324. No request hits the server.
Expected Behavior
Japanese IME should commit the selected candidate into the Cloud Agent chat, so I can write Japanese.
Preview should open the running app on the published port. If the app returns HTTP 200 on the VM, Preview should show that page, not ERR_EMPTY_RESPONSE.
Preview: bind your dev server to 0.0.0.0 instead of 127.0.0.1 and the preview should load (a loopback-only bind can’t be reached, which is why curl works on the VM but no request comes through). Let me know if that does it.
Japanese IME: that’s not intended behavior, and it’s not on your end. We’ve let the team know. Is it happening in the browser at cursor.com/agents, the desktop app, or both? A short screen recording of a candidate failing to insert would help a lot.
start script: next start --port 4521 --hostname 0.0.0.0 --keepAliveTimeout 70000
HTTP 200 from every address on the VM: 127.0.0.1, localhost, [::1], 0.0.0.0
and the container IP 172.30.0.2. A Cloudflare quick tunnel pointed at the
same port also serves the site to the public internet with 200, so the
listener is reachable from outside the VM by a path that does not involve
Preview. Preview still returned ERR_EMPTY_RESPONSE / ERR_CONNECTION_REFUSED
and no request ever reached the process.
One caveat on my side: this run has no ports declaration. I added "ports": [{ "name": "web", "port": 4521 }] to .cursor/environment.json
mid-session, and that only applies to newly started agents. If Preview
requires a declared port, this session was never a valid test. I will retest
with a fresh agent that boots with the declaration and report back.
As a workaround for anyone hitting this: a cloudflared quick tunnel to the
local port gives a working https URL and bypasses Preview entirely.
IME: it happens in the browser at cursor.com/agents. I will attach a
recording of a candidate failing to insert.
Since you were already on 0.0.0.0 and the port is reachable externally, loopback wasn’t it. A fresh agent that boots with "ports": [{ "name": "web", "port": 4521 }] is the right test, so keen to hear how that goes.
On the IME side, thanks for confirming it’s the browser at cursor.com/agents. The recording will help us pin down the candidate-commit failure, so send it over whenever you get a chance.