Cursor server stopped working because of base64 option -D

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Hi,

all my containers are based on alpine docker images, which i’m also using as devcontainer.
Today i did an cursor update and devcontainer functionality stopped working. Error message is:

2026-04-28 14:22:40.598 [info] Server install command exit code: 1
2026-04-28 14:22:40.598 [error] Failed to install remote server in container: Error: Couldn’t install Cursor Server, install script returned non-zero exit status
2026-04-28 14:22:40.599 [error] Error resolving dev container authority Couldn’t install Cursor Server, install script returned non-zero exit status
2026-04-28 14:22:40.599 [info] [server install] stderr: base64: unrecognized option: D

2026-04-28 14:22:40.600 [info] [server install] stderr: BusyBox v1.37.0 (2025-12-16 14:19:28 UTC) multi-call binary.

Usage: base64 [-d] [-w COL] [FILE]

Base64 encode or decode FILE to standard output

-d	Decode data
-w COL	Wrap lines at COL (default 76, 0 disables)

my ubuntu machine also doesn’t know base64 -D
It only knows -d or --decode

What’s wrong?

Steps to Reproduce

update cursor. open devcontainer.

Expected Behavior

cursor server should be installed properply-

Operating System

Linux

Version Information

Version: 3.2.11 (user setup)
VSCode Version: 1.105.1
Commit: e9ee1339915a927dfb2df4a836dd9c8337e17cc0
Date: 2026-04-24T14:36:47.933Z
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: Windows_NT x64 10.0.26100

Does this stop you from using Cursor

Yes - Cursor is unusable

5

Hey, this is a known bug on our side. The install script for the remote Cursor Server uses base64 -D, which is a macOS-only flag, so it won’t work on Linux or BusyBox. It’s on our radar and the fix is in the backlog, but we don’t have a clear ETA yet.

While it’s being fixed, the only reliable workaround is to roll back to a previous Cursor version where devcontainers still worked fine for you. You can download older builds here: Cursor · Download

Related thread with the same symptom: Remote Containers do not work with Alpine Docker images

7

Hello Dean,

well that’s disapointing.

I went all the way from v3.2 back to the oldest available version v2.4

after installing a version i deleted cursor-server in my wsl environment

rm -rf ~/.cursor-server/bin/*

and started cursor. it reinstalled the server, for version 2.4 it looked like this:

Downloading Cursor Server for x64 (3e548838cf824b70851dd3ef27d0c6aae371b3f0)

But it still doesn’t work. There is no lower version than 2.4 to download.

So what to do now? Go for Windsurf or Antigravity?

8

I hear you, that’s frustrating. A rollback is a bad Plan B, and it sucks it didn’t work. Most likely the install script gets updated on the server side when you connect, so downgrading the client doesn’t help.

While the fix is still in the backlog, here are a couple of Dockerfile-side workarounds.

Option 1: switch the base image
If Alpine isn’t critical, switch to node:22-slim or python:3.12-slim or any Debian-based image. The image alone won’t fix it since GNU base64 on Linux also doesn’t support -D, but together with Option 2 it’s cleaner.

Option 2: add a base64 wrapper that maps -D to -d

For Alpine:

RUN apk add --no-cache bash libstdc++ wget \
 && mv /usr/bin/base64 /usr/bin/base64.real \
 && printf '#!/bin/sh\nif [ "$1" = "-D" ]; then shift; exec /usr/bin/base64.real -d "$@"; fi\nexec /usr/bin/base64.real "$@"\n' > /usr/bin/base64 \
 && chmod +x /usr/bin/base64

For Debian or Ubuntu (base64 is already included):

RUN mv /usr/bin/base64 /usr/bin/base64.real \
 && printf '#!/bin/sh\nif [ "$1" = "-D" ]; then shift; exec /usr/bin/base64.real -d "$@"; fi\nexec /usr/bin/base64.real "$@"\n' > /usr/bin/base64 \
 && chmod +x /usr/bin/base64

It’s a dirty hack, but it should unpack the install script correctly until the IDE team removes -D from the fallback path.

If this doesn’t work for you, let me know and we’ll dig deeper. We’re tracking the issue on our side, and I’ll post an update here if there’s progress on the fix.

9

Unfortunately, this issue still hasn’t been fixed so far. My Cursor version information is as follows:

Version: 3.4.1 (user setup)
VSCode Version: 1.105.1
Commit: 2a298dd06944a9b9ea541d28225b779fcbcc6200
Date: 2026-05-08T16:05:07.818Z
Layout: editor
Build Type: Stable
Release Track: Nightly
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.26200

10

Hey @Tostar, confirmed. The bug is still in the backlog, and there’s no ETA for a fix yet.

While we’re waiting, there’s a Dockerfile workaround earlier in the thread, post #8: Cursor server stopped working because of base64 option -D - #8 by deanrie. It wraps base64 with a shell script that maps -D to -d. It works on Alpine and Debian/Ubuntu. It’s a bit of a dirty hack, but it lets devcontainers start up until the IDE team removes -D from the fallback path.

If you apply the workaround and it still doesn’t work, please share the logs from [server install] and we’ll take a look.

11

my devcontainer is based on image webdevops/php-nginx-dev:8.4-alpine

with these instructions added to my dockerfile the cursor server successfuilly installed:

######## Cursor dev container fixes (Alpine/BusyBox vs GNU) #########
### base64: https://forum.cursor.com/t/cursor-server-stopped-working-because-of-base64-option-d/159260/8?u=aleex1848 ###
### flock: Cursor install script uses flock -w; BusyBox flock has no -w (apk package util-linux flock) ###
RUN apk add --no-cache bash libstdc++ wget coreutils flock \
 && mkdir -p /usr/local/libexec/cursor-bin \
 && ln -sf "$(readlink -f /bin/base64)" /usr/local/libexec/cursor-bin/base64 \
 && printf '#!/bin/sh\nif [ "$1" = "-D" ]; then shift; exec /usr/local/libexec/cursor-bin/base64 -d "$@"; fi\nexec /usr/local/libexec/cursor-bin/base64 "$@"\n' > /usr/local/bin/base64 \
 && chmod +x /usr/local/bin/base64 \
 && ln -sf /usr/local/bin/base64 /usr/bin/base64 \
 && ln -sf /usr/local/bin/base64 /bin/base64
13

Great find, and thanks for coming back with a full fix. Good call on flock -w, BusyBox flock really doesn’t support it, so using util-linux or flock makes sense and closes the second gap. I’ll add this flock detail to what we already track around base64 so the fix covers both at once.

If you hit the same thing on Alpine, the workaround from post #11 has two parts:

  • base64: just running apk add coreutils isn’t enough. The install script calls base64 -D, and the -D flag isn’t supported by either BusyBox or GNU base64, they only support -d. You need a small wrapper script that intercepts -D and swaps it to -d (full version in post #11).
  • flock: this one’s easier. apk add --no-cache flock (or util-linux) installs a version that supports -w, so the flock-based lock issue goes away.

No ETA for our side fix yet, but I’ll post here once there’s an update. I’ll pin your post as the solution in the thread.

16

Hi @aleex1848 @Tostar

Thanks again for reporting this! The issue should now be resolved in the latest version of the SSH extension (v1.1.12). If you still encounter an issue after updating, please raise a new thread.