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.