GitHub Codespaces

リポジトリとブランチを選び、Codespaceを作成するだけ。
メインの物理マシンでなかったり、気が向いたときにブラウザ上で完結させたい時にも利用できる。

ファイル編集だけなら、GitHubのWebエディタを使えばよいのでCodespaceを立ち上げる必要すらない。

Windows VSCodeでWSLに接続せずに起動

何もせずに、起動できる。
アクセス経路はDocker -> /mnt/（ドライブレター）となっていると思われる。

ホスト側のストレージが開発ドライブ（ReFS）になっていると、例えば、Node.js環境のyarn create next-appやyarn installなどで、ファイル権限による書き込みエラーが発生する。
NTFSでは発生しないので、何かありそう。（2024/7時点）

Windows VSCodeでWSL上のLinuxまたは直接Linuxに接続して起動

主流となっているコンテナー技術はLinuxなので、Linux環境であれば何のトラブルもなく扱えるはず。
WSL経由の場合は若干違うものの、昔ほど特殊ではないなら気にならなくなった。

WSLの場合、注意するのはWSLに割り当てているメモリ容量くらい。
デフォルトではホストのメモリのうち、最大1/2が利用可能。
.wslconfigを編集して調整することもできる。

WSL での詳細設定の構成 | Microsoft Learn

Mac VSCodeで起動

一応、起動する。
WSLのような高パフォーマンスな専用サブシステムがないものの。

開発コンテナーというより、Dockerそのものに関する話として、macOSはUNIXが派生元なのでカーネルレベルではLinuxと互換がない点でWindowsと一緒。
zshはあくまでUIレベルの話だから、Mac環境でDockerを使おうとしてる人は痛い目を見る。
Macの場合はLinux環境を別に用意した方がよい。

あと、CPUで言えば、Apple SiliconのMシリーズとCopliot + PCのSnapdragon X EliteはARMなので、x86依存パッケージなどは使えない（Debian系ならaptのリストに出てこない）。
x86エミュレートでチャレンジしてもいいが、駄目なものは駄目のパターンもある。OSが吐くエラーを解析する気がない他力本願な人なら、ARMは最初から除外した方がいい。
別の方法でインストール手段があればそれを利用する、パッケージは諦める、ソースからビルドするの選択肢。
今時、パッケージ管理されてないものをconfigure、makeなんてしたくない。