Cursor Chat Fails with “Invalid Time Zone: Etc/Unknown” on macOS (Remote SSH)

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

I am seeing a reproducible Cursor chat failure on macOS with the following error:

Request ID: b919c14f-d363-47ea-94bb-3b2de447ce3f
[internal] Invalid time zone specified: Etc/Unknown
aae: [internal] Invalid time zone specified: Etc/Unknown
at rK_ (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:28926:24637)
at nK_ (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:28926:23543)
at dK_ (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:28927:6487)
at h8u.run (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:28927:11285)
at async xDn.runAgentLoop (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:41235:11960)
at async W1d.streamFromAgentBackend (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:41305:12151)
at async W1d.getAgentStreamResponse (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:41305:18486)
at async N3e.submitChatMaybeAbortCurrent (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:29033:16809)
at async Object.Va [as onSubmit] (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:40288:4233)
at async vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:40287:100561

What I verified:
macOS timezone settings are valid
launching Cursor with TZ=Etc/UTC still fails
remote host timezone checks return UTC
The issue occurs when starting a new chat

This appears to match the confirmed Cursor bug related to Etc/Unknown, but in my case, both local and remote timezone checks appear valid.

Steps to Reproduce

Just installed the latest version: 3.1.17, and started a new chat.

Operating System

MacOS

Version Information

Version: 3.1.17
VSCode Version: 1.105.1
Commit: fce1e9ab7844f9ea35793da01e634aa7e50bce90
Date: 2026-04-19T19:33:58.189Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Darwin arm64 25.4.0

Does this stop you from using Cursor

Yes - Cursor is unusable

7

Hi Anas!

This is a known bug on our side — a few other users have reported the same error on Windows and Docker/Linux environments. Cursor’s server doesn’t properly validate the timezone string sent from the client, so when the system reports “Etc/Unknown”, it crashes instead of falling back to UTC.

Since you’re using Remote SSH, the timezone is likely being resolved from the remote host’s environment, not your local macOS. Even if timedatectl or date shows UTC on the remote, the Node.js runtime Cursor uses may resolve it differently if the remote host is missing proper timezone data.

A few things to try on the remote host:

  1. Install tzdata if it’s a minimal Linux installation:

    sudo apt-get install -y tzdata
    sudo ln -fs /usr/share/zoneinfo/UTC /etc/localtime
    echo "UTC" | sudo tee /etc/timezone
    sudo dpkg-reconfigure -f noninteractive tzdata

    (Adjust for your package manager if not Debian/Ubuntu.)

  2. Set TZ in your remote shell profile (~/.bashrc or ~/.profile):

    export TZ=UTC

  3. Fully restart Cursor (quit entirely, not just reload window) after making these changes, so the Remote SSH extension host picks up the new timezone.

You can verify by opening Developer Tools (Help > Toggle Developer Tools) on the remote connection and running in the Console:

new Intl.DateTimeFormat('en-US', { timeZone: Intl.DateTimeFormat().resolvedOptions().timeZone })

If this throws an error, the timezone data still isn’t set up correctly on the remote.

A server-side fix is in the works so this won’t crash regardless of what the OS reports. Let me know if any of the above helps!