Code-Server Git issues + Installing addons #65

New Issue

2026-05-29T14:42:22-04:00

sickprodigy commented

2026-05-29 14:42:22 -04:00

What you’re hitting is usually one of these:

line ending differences (CRLF on Windows vs LF on Linux/container)
file permission mode changes (chmod)
Git safecrlf/autocrlf mismatches
differing formatter settings/extensions between local VS Code and code-server
different .gitattributes handling

The most common issue is Windows using CRLF while your Linux Docker/code-server uses LF.

Recommended Fix

Use LF everywhere, even on Windows.

In your Windows VS Code:

Bottom-right corner → click CRLF
Change to LF
Save files

Then set Git properly on Windows:

git config --global core.autocrlf input

Or if you want Windows apps to still use CRLF outside Git:

git config --global core.autocrlf false

Avoid true if you're sharing repos between Linux containers and Windows.

Add a .gitattributes

In the repo root:

text=auto eol=lf

Or stricter:

text eol=lf

This forces consistent line endings everywhere.

Then normalize once:

git add --renormalize .
git commit -m "Normalize line endings"
Check What Git Thinks Changed

Run:

git diff

If nothing visible appears, try:

git diff --ignore-space-at-eol

Or:

git status --porcelain=v2

If it’s permissions:

git config core.fileMode false

Usually needed when Windows touches repos hosted on Linux.

Best Setup For Your Workflow

Since you already host code-server remotely:

Option 1 (cleanest)

Use VS Code Remote SSH instead of editing local copies.

Use the official VS Code extension:

Visual Studio Code Remote - SSH

Connect directly to the server and edit the same filesystem code-server uses.

Then:

one Git install
one filesystem
one set of line endings
no sync weirdness

You can still use code-server in browser when needed.

Option 2

Keep local Windows clone + remote clone, but enforce:

.gitattributes
LF only
same formatter/extensions
same prettier/eslint configs
Also Check VS Code Settings

In both environments:

"files.eol": "\n"

And preferably:

"editor.formatOnSave": true

with identical formatter extensions installed.

Quick Diagnostic

Run this inside the repo on the server:

git diff --summary

If you see:

mode change 100644 => 100755

then it’s permissions.

If entire files appear modified but content looks identical, it’s almost certainly CRLF/LF.

What you’re hitting is usually one of these: line ending differences (CRLF on Windows vs LF on Linux/container) file permission mode changes (chmod) Git safecrlf/autocrlf mismatches differing formatter settings/extensions between local VS Code and code-server different .gitattributes handling The most common issue is Windows using CRLF while your Linux Docker/code-server uses LF. Recommended Fix Use LF everywhere, even on Windows. In your Windows VS Code: Bottom-right corner → click CRLF Change to LF Save files Then set Git properly on Windows: git config --global core.autocrlf input Or if you want Windows apps to still use CRLF outside Git: git config --global core.autocrlf false Avoid true if you're sharing repos between Linux containers and Windows. Add a .gitattributes In the repo root: * text=auto eol=lf Or stricter: * text eol=lf This forces consistent line endings everywhere. Then normalize once: git add --renormalize . git commit -m "Normalize line endings" Check What Git Thinks Changed Run: git diff If nothing visible appears, try: git diff --ignore-space-at-eol Or: git status --porcelain=v2 If it’s permissions: git config core.fileMode false Usually needed when Windows touches repos hosted on Linux. Best Setup For Your Workflow Since you already host code-server remotely: Option 1 (cleanest) Use VS Code Remote SSH instead of editing local copies. Use the official VS Code extension: Visual Studio Code Remote - SSH Connect directly to the server and edit the same filesystem code-server uses. Then: one Git install one filesystem one set of line endings no sync weirdness You can still use code-server in browser when needed. Option 2 Keep local Windows clone + remote clone, but enforce: .gitattributes LF only same formatter/extensions same prettier/eslint configs Also Check VS Code Settings In both environments: "files.eol": "\n" And preferably: "editor.formatOnSave": true with identical formatter extensions installed. Quick Diagnostic Run this inside the repo on the server: git diff --summary If you see: mode change 100644 => 100755 then it’s permissions. If entire files appear modified but content looks identical, it’s almost certainly CRLF/LF.

sickprodigy commented

2026-05-29 14:42:57 -04:00

Best Method for container mods/addons

Create your own image:

FROM lscr.io/linuxserver/code-server:latest

RUN apt update && apt install -y
git
python3
python3-pip
nodejs
npm
build-essential
ripgrep
fd-find
zsh
nano
htop
&& rm -rf /var/lib/apt/lists/*

Then either:

build locally in Portainer
or use GitHub Container Registry / Docker Hub
Easiest Portainer Workflow
Option A — Build From Git Repo

Portainer supports this directly.

Make a tiny GitHub repo:

Dockerfile
docker-compose.yml (optional)

Then in Portainer:

Stacks → Add Stack → Build method: Git Repository

Point it at your repo.

Now every time LinuxServer updates:

your image rebuilds
latest code-server pulls automatically
your packages remain installed

Because:

FROM lscr.io/linuxserver/code-server:latest

always tracks upstream.

This Is MUCH Better Than Forking

If you forked actual code-server:

you'd need to merge upstream constantly
rebuild the app
maintain node build chains
handle release breakage

With derived images:

upstream updates remain automatic
almost zero maintenance
only your added packages layer on top
Even Easier: Docker Mods

LinuxServer actually has a feature specifically for this:

Docker Mods

LinuxServer Docker Mods docs

These let you inject packages/features without custom builds.

Example in Portainer:

environment:

DOCKER_MODS=linuxserver/mods:code-server-python3

There are existing mods for:

Python
Node
Docker CLI
etc.

But honestly, custom image is cleaner long-term.

My Recommendation For Your Setup

Since you're doing:

remote development
agents/OpenHands
Docker
AI tooling

I’d build a permanent dev image.

Something like:

FROM lscr.io/linuxserver/code-server:latest

RUN apt update && apt install -y
git
python3
python3-pip
python3-venv
nodejs
npm
build-essential
docker.io
docker-compose
ripgrep
fd-find
jq
curl
wget
unzip
zip
nano
zsh
htop
tmux
&& rm -rf /var/lib/apt/lists/*

That becomes basically:

your cloud VS Code workstation
persistent dev environment
AI agent environment
Docker management node
One More Important Recommendation

Mount your Docker socket:

volumes:

/var/run/docker.sock:/var/run/docker.sock

Then install Docker CLI inside container.

Now code-server can:

manage containers
run compose
build images
use OpenHands properly
control your server directly

Very useful setup.

Best Method for container mods/addons Create your own image: FROM lscr.io/linuxserver/code-server:latest RUN apt update && apt install -y \ git \ python3 \ python3-pip \ nodejs \ npm \ build-essential \ ripgrep \ fd-find \ zsh \ nano \ htop \ && rm -rf /var/lib/apt/lists/* Then either: build locally in Portainer or use GitHub Container Registry / Docker Hub Easiest Portainer Workflow Option A — Build From Git Repo Portainer supports this directly. Make a tiny GitHub repo: Dockerfile docker-compose.yml (optional) Then in Portainer: Stacks → Add Stack → Build method: Git Repository Point it at your repo. Now every time LinuxServer updates: your image rebuilds latest code-server pulls automatically your packages remain installed Because: FROM lscr.io/linuxserver/code-server:latest always tracks upstream. This Is MUCH Better Than Forking If you forked actual code-server: you'd need to merge upstream constantly rebuild the app maintain node build chains handle release breakage With derived images: upstream updates remain automatic almost zero maintenance only your added packages layer on top Even Easier: Docker Mods LinuxServer actually has a feature specifically for this: Docker Mods [LinuxServer Docker Mods docs](https://mods.linuxserver.io/?utm_source=chatgpt.com) These let you inject packages/features without custom builds. Example in Portainer: environment: - DOCKER_MODS=linuxserver/mods:code-server-python3 There are existing mods for: Python Node Docker CLI etc. But honestly, custom image is cleaner long-term. My Recommendation For Your Setup Since you're doing: remote development agents/OpenHands Docker AI tooling I’d build a permanent dev image. Something like: FROM lscr.io/linuxserver/code-server:latest RUN apt update && apt install -y \ git \ python3 \ python3-pip \ python3-venv \ nodejs \ npm \ build-essential \ docker.io \ docker-compose \ ripgrep \ fd-find \ jq \ curl \ wget \ unzip \ zip \ nano \ zsh \ htop \ tmux \ && rm -rf /var/lib/apt/lists/* That becomes basically: your cloud VS Code workstation persistent dev environment AI agent environment Docker management node One More Important Recommendation Mount your Docker socket: volumes: - /var/run/docker.sock:/var/run/docker.sock Then install Docker CLI inside container. Now code-server can: manage containers run compose build images use OpenHands properly control your server directly Very useful setup.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: sickprodigy/docker-home-server#65