Native Support for VS Code Remote (SSH) / Antigravity Connections

[yougotborked]

Describe the feature

I would like to request native support for connecting to the Home Assistant OS host using VS Code Remote (SSH). Currently, the connection fails because the host (Alpine Linux) lacks the necessary glibc compatibility libraries required by the VS Code Server (Node.js binary) and because SSH TCP forwarding is disabled by default.
Specifically, we need:

1. Glibc Compatibility: A supported way to run glibc-linked binaries. The gcompat package is often insufficient (missing symbols like fcntl64). We found that sgerrand/alpine-pkg-glibc works but requires manual installation.
2. Compatible C++ Libraries: The system libstdc++ is linked against musl. External binaries need a glibc-compatible libstdc++.so.6.
3. SSH Forwarding: The default sshd_config has AllowTcpForwarding no, which blocks the VS Code connection tunnel. This should be enabled or configurable.

Use cases

• AI-Assisted Configuration: Leveraging tools like GitHub Copilot or Antigravity to generate and optimize Home Assistant automations and YAML configurations directly on the host.
• Advanced Debugging: Developers can debug Home Assistant Core, Supervisor, or OS issues directly on the host using a full-featured IDE.
• System Management: Easier management of Docker containers, configuration files, and system logs via the VS Code interface.
• Remote Development: Facilitates developing add-ons or integrations that require host-level access.

Current workarounds

We successfully established a connection by manually modifying the host (which is not persistent or recommended for production):

1. Installed sgerrand/alpine-pkg-glibc (v2.35).
2. Manually extracted libstdc++.so.6 and libgcc_s.so.1 from Debian Bullseye (GCC 10) packages and placed them in /usr/glibc-compat/lib. (Newer Debian versions were incompatible with the available alpine-glibc version).
3. Created a symlink /lib64/ld-linux-x86-64.so.2 pointing to the glibc loader.
4. Edited /etc/ssh/sshd_config to set AllowTcpForwarding yes and restarted the SSH service.

Anything else?

The specific incompatibility found was that the system's libstdc++ could not be loaded by the glibc-linked Node binary because it depended on musl symbols. Providing a separate, glibc-compatible libstdc++ in a compatibility path (like /usr/glibc-compat/lib) is critical.
Also, the "administratively prohibited" error for the SOCKS tunnel was purely due to AllowTcpForwarding no.

[douglascrc-git]

I second your petition! It'd be really usefull!

[love4taylor]

VS Code Server supports musl—at the very least, version 1.108.2 (Universal) does. So the problem is on Antigravity’s side; they didn’t handle it.

so-net-homelab:~$ file .antigravity-server/bin/7a8657542180fb8440c8dcc20d83285fe11360ed/node
.antigravity-server/bin/7a8657542180fb8440c8dcc20d83285fe11360ed/node: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=3041231d7c58acd5df3f437e19bb151d38b7fa5d, for GNU/Linux 3.2.0, with debug_info, not stripped, too many notes (256)

so-net-homelab:~$ file .vscode-server/cli/servers/Stable-c9d77990917f3102ada88be140d28b038d1dd7c7/server/node
.vscode-server/cli/servers/Stable-c9d77990917f3102ada88be140d28b038d1dd7c7/server/node: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-musl-x86_64.so.1, with debug_info, not stripped

UPDATE:
What’s kind of funny is that after I replaced Antigravity’s Node binary with VSCode’s, it worked fine. Something that could clearly be solved with a simple detection script to fetch the right binary for different environments, and yet Google can’t even do it right.

UPDATE2:

The Pty Host reports the following error; on Alpine, /bin/sh points to busybox.

2026-01-25 23:27:45.538 [warning] Shell integration cannot be enabled for executable "/bin/sh" and args []
2026-01-25 23:27:45.911 [warning] Shell integration cannot be enabled for executable "/bin/sh" and args []
2026-01-25 23:27:46.273 [warning] Shell integration cannot be enabled for executable "/bin/sh" and args []
2026-01-25 23:27:46.931 [warning] Shell integration cannot be enabled for executable "/bin/sh" and args []
2026-01-25 23:27:47.455 [error] [RPC Response] PtyService#updateIcon Could not find pty 1 on pty host
2026-01-25 23:27:47.623 [warning] Shell integration cannot be enabled for executable "/bin/sh" and args []
2026-01-25 23:27:48.184 [warning] Shell integration cannot be enabled for executable "/bin/sh" and args []
2026-01-25 23:27:48.530 [warning] Shell integration cannot be enabled for executable "/bin/sh" and args []
2026-01-25 23:27:49.370 [error] [RPC Response] PtyService#updateIcon Could not find pty 1 on pty host
2026-01-25 23:29:53.486 [warning] Shell integration cannot be enabled for executable "/bin/sh" and args []
2026-01-25 23:36:56.472 [warning] Shell integration cannot be enabled for executable "/bin/sh" and args []
2026-01-25 23:43:56.394 [warning] Shell integration cannot be enabled for executable "/bin/sh" and args []
2026-01-25 23:46:28.838 [warning] Shell integration cannot be enabled for executable "/bin/sh" and args []
2026-01-25 23:51:28.583 [warning] Shell integration cannot be enabled for executable "/bin/sh" and args []
2026-01-25 23:55:08.491 [warning] Shell integration cannot be enabled for executable "/bin/sh" and args []
2026-01-25 23:57:00.210 [warning] Shell integration cannot be enabled for executable "/bin/sh" and args []