Devcontainer on ポンコツ地方エンジニアの技術ブログ

Claude Code の認証情報とチャット履歴を devcontainer とホストで共有する

Wed, 13 May 2026 00:00:00 +0900

環境

Ubuntu 24.04
VSCode 1.119.0

きっかけ

devcontainer をリビルドするたびに Claude Code に再ログインするのが地味にストレスでした。さらに、ホスト側で進めていた会話の続きが devcontainer 側からは見えず、「あの修正の文脈どこに残してたっけ」となりがちでした。

ゴール構成

ホスト・devcontainer のどちらで起動しても 同じ認証情報 を使える
ホストで途中まで進めた会話を devcontainer 側でも そのまま継続 できる
リビルドしても再ログイン不要

Claude Code が何を見ているかを把握する

設定の前に、Claude Code が以下の 2 つを参照していることを押さえておきます。

種類	場所	役割
認証情報・設定	`~/.claude.json`	API キーなど
セッション履歴	`~/.claude/projects/<エンコードしたパス>/`	プロジェクトごとの会話履歴

ポイントは、セッション履歴の格納先が プロジェクトの絶対パスをスラッシュ → ハイフンに変換した名前 になっていることです。

例えばホスト側で /home/<username>/<project_name> を開いていた場合は、

~/.claude/projects/-home-<username>-<project_name>/

の下に履歴が溜まります。

つまり、履歴を共有したいなら ホストとコンテナで「ワークスペースの絶対パス」を一致させる必要がある ということです。~/.claude だけ bind mount しても、コンテナ側のワークスペースパスがホストと違えば別フォルダ扱いになり、履歴は共有されません。

設定する 2 つのマウント

必要なマウントは性質の違う 2 種類になります。

1. `.claude` / `.claude.json` のマウント (= コンテナ側ユーザーの home に合わせる)

Claude Code は そのプロセスの $HOME/.claude を読みに行きます。devcontainer のデフォルトユーザーは vscode なので、~ は /home/vscode です。したがってターゲットも /home/vscode/.claude にします。

2. ワークスペースのマウント (= ホスト側の絶対パスに合わせる)

こちらはセッション履歴のキーになる「プロジェクトの絶対パス」を一致させるのが目的なので、ターゲットを ホスト側と同じパス にします。ホストの ~/<project_name> を開いているなら、コンテナ内でも /home/<username>/<project_name> にマウントするということです。

ターゲットの基準が違う (ユーザー基準 vs ホスト基準) のがややこしい部分なので、表にしておきます。

マウント	ターゲット	基準
`~/.claude` `~/.claude.json`	`/home/vscode/.claude` `/home/vscode/.claude.json`	コンテナ内ユーザーの home
ワークスペース	`/home/<username>/<project_name>` 等	ホスト側の絶対パス

devcontainer.json の例

上記を踏まえた .devcontainer/devcontainer.json の抜粋です。

{
 "name": "my-devcontainer",
 "build": {
 "dockerfile": "Dockerfile",
 "args": {
 // ホストの $HOME を build arg として Dockerfile に渡す
 // (workspace の親ディレクトリを事前に作るために使う。後述)
 "WORKSPACE_PARENT": "${localEnv:HOME}"
 }
 },

 // ワークスペースのマウント先をホスト側の絶対パスと一致させる。
 // フォルダ名は localWorkspaceFolderBasename で動的解決するので、
 // ホスト側を rename しても devcontainer.json の編集は不要。
 "workspaceMount": "source=${localWorkspaceFolder},target=${localEnv:HOME}/${localWorkspaceFolderBasename},type=bind,consistency=cached",
 "workspaceFolder": "${localEnv:HOME}/${localWorkspaceFolderBasename}",

 "mounts": [
 // .claude / .claude.json はコンテナ内ユーザー (vscode) の home にマウント
 "source=${localEnv:HOME}/.claude,target=/home/vscode/.claude,type=bind,consistency=cached",
 "source=${localEnv:HOME}/.claude.json,target=/home/vscode/.claude.json,type=bind,consistency=cached"
 ],

 "remoteUser": "vscode"
}

${localEnv:HOME} は ホスト側 の $HOME (例: /home/<username>)、${localWorkspaceFolderBasename} は VSCode が開いているフォルダ名 (例: <project_name>) に展開されます。両者を組み合わせることで、ホストで開いているパスと完全に同じ絶対パスをコンテナ内に作れます。

Dockerfile 側で親ディレクトリを用意しておく

workspaceFolder に指定したパスの 親ディレクトリ がコンテナ内に存在しないと、Dev Containers の起動チェックで「ワークスペースが存在しません」とエラーになります。bind mount はマウント時にターゲットを作ってくれますが、Dev Containers のチェックがそれより先に走るためです。

そこで Dockerfile 側で親ディレクトリだけ先に作っておきます。

FROM mcr.microsoft.com/devcontainers/base:bookworm

# devcontainer.json の workspaceFolder (= ホストの $HOME/<フォルダ名>) と
# 同じ絶対パスをコンテナ内に用意しておく。
ARG WORKSPACE_PARENT=/home/vscode
RUN mkdir -p "${WORKSPACE_PARENT}"

ARG のデフォルト値を /home/vscode にしておけば、build arg を渡し忘れても既存ユーザーのホームが使われるだけで build が壊れることはありません。

ユーザーは vscode のままでよい

「ワークスペースが /home/<username>/<project_name> なのに whoami すると vscode になっている」というアンバランスさが気になるかもしれませんが、機能上は問題ありません。

devcontainers/base の vscode ユーザーは UID 1000
ホスト側の Linux ユーザーも通常 UID 1000

UID が一致していれば bind mount したファイルにそのまま読み書きできるためです。vscode ユーザーが自分の home (/home/vscode/) 以外の場所で作業すること自体は何も問題を起こしません。

ユーザー名まで揃えようとすると base image の改造が必要になり、devcontainer features が前提にしている vscode ユーザーが消えて壊れがちです。ホストと揃えるのは「絶対パス」だけで十分 と割り切るのが楽です。

注意点

ホスト側に ~/.claude と ~/.claude.json が存在している必要があります。なければ bind mount に失敗します。ホスト側でも一度 Claude Code を起動して認証を済ませておくのが手っ取り早いです。
セッション履歴を ホストと同時に書き込まない よう注意してください。両方から同じプロジェクトを同時に触ると、ファイルロック等の衝突で履歴が壊れることがあります。基本「どちらか一方で作業する」運用が安全です。
設定変更後は VSCode の Dev Containers: Rebuild Container でリビルドしないと反映されません。

まとめ

Claude Code のセッション履歴は プロジェクトの絶対パスをキー にして格納される。
なので「ホストとセッション共有したい」ならコンテナ内のワークスペースパスをホスト側と完全一致させる必要がある。
マウント先は 2 系統で基準が違う:
- .claude / .claude.json は コンテナ内ユーザーの home に合わせる
- ワークスペースは ホスト側の絶対パス に合わせる
ワークスペースの親ディレクトリは Dockerfile 側で mkdir -p しておく必要がある。
フォルダ名は ${localWorkspaceFolderBasename} で動的解決すれば、rename にも追従する。

GitHub CLI (gh auth login) で Git の HTTPS 認証を安全にする

Mon, 11 May 2026 00:00:00 +0900

環境

Ubuntu 24.04

きっかけ

git remote -v を眺めていたら、Personal Access Token (PAT) が remote URL に丸ごと埋め込まれている状態になっていました。

origin https://ghp_xxxxxxxxxxxxxxxxxxxxxxxxxxxx@github.com/USER/REPO.git (fetch)
origin https://ghp_xxxxxxxxxxxxxxxxxxxxxxxxxxxx@github.com/USER/REPO.git (push)

.git/config はリポジトリに含まれないため「push しても外には出ない」ものの、ローカルで露出する経路は意外と多くあります。

シェル履歴 (~/.bash_history ~/.zsh_history)
エディタや CI のログ、画面共有・スクリーンショット
うっかり配布した dotfiles リポジトリ
マルウェアやリモートアクセスで .git/config が読まれる

しかも classic PAT はスコープが粗く、repo 権限があれば private リポジトリ全体の閲覧・書き換え、強制 push による履歴破壊、GitHub Actions secrets の窃取まで可能になります。攻撃者は奪った瞬間には何もせず静かに watch することもできるため、「使われた形跡がない」では安心できません。

これを機に、PAT を URL に埋めず GitHub CLI (gh) の credential helper に任せる構成に切り替えました。

ゴール構成

remote URL は素の https://github.com/USER/REPO.git
認証は gh が credential helper として処理 (トークンは OS のセキュアストア管理)
devcontainer を作り直しても再ログイン不要

手順

1. 露出したトークンを revoke (最優先)

remote URL を書き換える前に、まず GitHub 側でトークンを無効化します。

classic PAT: https://github.com/settings/tokens
fine-grained PAT: https://github.com/settings/personal-access-tokens

該当トークンを Delete した瞬間に無効になります。順序として これを先にやる ことが大切です。後の手順を待っている間に古いトークンが他経路で使われるリスクを断ちます。

2. `gh` をインストール

devcontainer 環境なら ghcr.io/devcontainers/features/github-cli feature で gh がすでに入っています。

ホスト (Ubuntu 24.04) に入れる場合は、以下の記事を参考にしてください。

GitHub CLI (gh) のインストールと基本的な使い方

3. `gh auth login` で認証

gh auth login

対話で以下のように選びます。

? Where do you use GitHub? GitHub.com
? What is your preferred protocol for Git operations? HTTPS
? Authenticate Git with your GitHub credentials? Yes
? How would you like to authenticate GitHub CLI? Login with a web browser

Authenticate Git with your GitHub credentials? → Yes が肝で、これが git config --global credential.helper を gh 経由に書き換えてくれます。以後 git push のたびに gh が裏でトークンを取り出して認証してくれます。

devcontainer のようなヘッドレス環境ではブラウザは自動で開きません。表示される 8 桁のワンタイムコードをコピーし、ホスト側のブラウザで https://github.com/login/device に貼って承認します。

✓ Authentication complete.
✓ Logged in as USER

4. remote URL からトークンを除去

git remote set-url origin https://github.com/USER/REPO.git
git remote -v

トークン部分が消えていれば OK です。git fetch origin がパスワードを聞かれずに通れば認証は機能しています。

5. シェル履歴の残骸を確認

revoke 済みでも、ローカル履歴に残ったトークン文字列は気持ちが悪いものです。

grep -rn 'ghp_' ~/.bash_history ~/.zsh_history 2>/dev/null

ヒットしたら該当行を削除します (history -d <行番号> でメモリ上を消した後、ファイルも編集しておきます)。

devcontainer での認証共有

gh の認証情報は ~/.config/gh/hosts.yml (と OS のセキュアストア) に保存されます。devcontainer をリビルドすると ~/.config/gh が消えて再ログインが必要になるため、ホストの設定を bind mount で共有します。

.devcontainer/devcontainer.json:

"mounts": [
 "source=${localEnv:HOME}/.claude,target=/home/vscode/.claude,type=bind,consistency=cached",
 "source=${localEnv:HOME}/.claude.json,target=/home/vscode/.claude.json,type=bind,consistency=cached",
 "source=${localEnv:HOME}/.config/gh,target=/home/vscode/.config/gh,type=bind,consistency=cached"
]

前提として ホスト側に ~/.config/gh ディレクトリが存在している必要があります (なければ bind mount に失敗します)。ホストにも gh を入れて gh auth login 済みにしておくのが一番シンプルです。事情があってホスト側で gh を使わない場合でも、空ディレクトリだけ作っておけばマウント自体は通ります。

mkdir -p ~/.config/gh # ホスト側で実行

設定変更後は VSCode の Dev Containers: Rebuild Container でリビルドすると反映されます。

補足: SSH 鍵にしないのか

SSH 鍵認証もアリですが、

鍵ファイル自体の管理 (~/.ssh のパーミッション、複数マシン間の同期) が発生します
GitHub Actions など他用途で gh をどのみち使うことが多いです

そのため、個人開発の HTTPS なら gh auth login ひとつに寄せた方がメンテが楽だと感じています。複数アカウントの切替も gh auth switch で済むのが良いところです。

まとめ

PAT を URL に埋めるのは「公開リポジトリに含まれない」だけでローカル経路の露出リスクは大きいです。露出に気付いた時点で revoke が最優先となります。
gh auth login で credential helper を任せれば URL からトークンを排除でき、トークンは OS のセキュアストアに隔離されます。
devcontainer ではホストの ~/.config/gh を bind mount しておくと、リビルドのたびに再ログインしなくて済みます。

ターミナルから GitLab を操る：公式 CLI「glab」導入・活用ガイド

Sun, 10 May 2026 00:00:00 +0900

ブラウザを開かずに Issue を確認したり、MR（マージリクエスト）を作成したり、CI/CD パイプラインの状況を監視したりできるため、エンジニアの生産性を大きく向上させてくれます。

1. インストール方法

devcontainer を使っていない場合は、ホスト側に glab をインストールして使います。devcontainer を使う場合は、コンテナイメージに glab をインストールしておくか、devcontainer の Dockerfile / devcontainer.json で導入しておきます。

一般的な手順としては、Dockerfile に curl で glab の公式パッケージを取得して apt install するか、apt リポジトリからインストールする形です。コンテナ内で glab --version を実行して、インストールが正しくできていることを確認してください。

OS ごとの主要なインストールコマンドは以下の通りです。

OS	インストールコマンド
macOS	`brew install glab`
Windows (winget)	`winget install glab`
Windows (scoop)	`scoop install glab`
Linux (Ubuntu/Debian)	`sudo apt install glab`（※公式リポジトリ推奨）

インストール後、glab --version で正常にインストールされたか確認しましょう。

バージョンが古かったり、上記でインストールできない場合は、公式リリースからダウンロードしてインストールします。

https://gitlab.com/gitlab-org/cli/-/releases

例えば以下です。

cd /tmp
wget https://gitlab.com/gitlab-org/cli/-/releases/v1.97.0/downloads/glab_1.97.0_linux_amd64.deb
sudo dpkg -i glab_1.97.0_linux_amd64.deb

2. 初期設定（認証）

インストールが完了したら、GitLab アカウントと連携させます。

glab auth login

実行すると対話形式で以下の項目を聞かれます：

GitLab インスタンスの種類: GitLab.com か自前運用のサーバー（Self-Managed）かを選択。
認証方法: Web を選択するとブラウザが開いて簡単に認証できます。
プロトコル: SSH または HTTPS を選択。

設定が完了すると、~/.config/glab-cli/config.yml に設定が保存されます。

3. devcontainer での認証情報共有

glab の認証情報は ~/.config/glab-cli/config.yml に保存されます。devcontainer をリビルドするとコンテナ内の ~/.config/glab-cli が消えて再ログインが必要になるため、ホスト側の設定を bind mount で共有しておくと便利です。

一般的には、.devcontainer/devcontainer.json の mounts にホストの ~/.config/glab-cli を追加します。例:

"mounts": [
 "source=${localEnv:HOME}/.config/glab-cli,target=/home/vscode/.config/glab-cli,type=bind,consistency=cached"
]

もし gh など別の CLI も devcontainer 内で使うなら、同じように ~/.config/gh を共有することもできます。

ホスト側に ~/.config/glab-cli が存在していれば、ホストで一度 glab auth login しておけばコンテナ側でも同じ認証を使えます。ホストにディレクトリがない場合は、mkdir -p ~/.config/glab-cli で空ディレクトリを作成しておけばマウントが通ります。

このようにしておけば、glab の認証設定をホストと devcontainer で共通化し、コンテナ再構築後も再ログイン不要で作業を続けやすくなります。

4. よく使う基本コマンド集

glab のコマンド体系は glab <リソース名> <アクション> という形式で、gh と非常に似ています。

■ Merge Request (MR) を操作する

開発のメイン作業となる MR 操作です。

MR の一覧表示: glab mr list
MR の作成: glab mr create --fill（現在のブランチから自動入力で作成）
MR の詳細表示: glab mr view <id>
MR を承認: glab mr approve <id>
MR をマージ: glab mr merge <id>

■ Issue (課題) を管理する

Issue 一覧: glab issue list
Issue 作成: glab issue create -t "タイトル" -description "内容"

■ CI/CD パイプラインを確認する

glab 独自の強力な機能の一つが、CI パイプラインのリアルタイム監視です。

パイプラインの状態表示: glab pipeline status
実行中のログをリアルタイム表示: glab pipeline ci view
失敗したジョブの再実行: glab ci retry

4. `gh` と `glab` の主な対応表

GitHub CLI に慣れている方向けのクイック比較です。

機能	GitHub (`gh`)	GitLab (`glab`)
認証	`gh auth login`	`glab auth login`
PR / MR 作成	`gh pr create`	`glab mr create`
PR / MR チェックアウト	`gh pr checkout <id>`	`glab mr checkout <id>`
リポジトリ作成	`gh repo create`	`glab project create`
CI 監視	`gh run watch`	`glab pipeline ci view`

5. 自社運用の GitLab (Self-Managed) で使うコツ

glab は GitLab.com だけでなく、会社などで独自に立てている GitLab サーバーでも使えます。その場合、環境変数でホストを指定しておくと便利です。

export GITLAB_HOST=gitlab.example.com

まとめ

glab を導入することで、「コードを書く → プッシュする → ブラウザで MR を作る → CI の完了を待つ」という一連の流れをターミナルから一歩も出ずに行えるようになります。

まずは glab mr list から始めて、快適な GitLab ライフを送りましょう！

参考リンク:

VSCode の Remote-Containers を起動したときに、マウントのパスに無効な文字が含まれているというエラーが表示された

Wed, 01 Sep 2021 00:00:00 +0900

ホストのディレクトリをコンテナにマウントしたかったのですが、以下のようなエラーが表示されました。

docker: Error response from daemon: create /home/user/workspace: "/home/user/workspace" includes invalid characters for a local volume name, only "[a-zA-Z0-9][a-zA-Z0-9_.-]" are allowed. If you intended to pass a host directory, use absolute path.

devcontainer.json の mounts の設定は以下です。

"mounts": [
	"source=${localWorkspaceFolder}/workspace,target=/workspace",
],

type を省略してしまっていたのですが、type のデフォルトは volume なので、ボリュームをマウントしようとしてエラーになっていたみたいです。
以下のように type=bind を指定したら上手くいきました。

"mounts": [
	"source=${localWorkspaceFolder}/workspace,target=/workspace,type=bind",
],

参考 URL

VSCode + Remote-Containers で python の開発環境を作成する

Fri, 18 Jun 2021 00:00:00 +0900

VSCode の Remote-Containers を使い、python 開発用の docker コンテナを作成し、そのコンテナ中で python のデバッグをできるようにします。

環境

Ubuntu 20.04
Visual Studio Code 1.56.2
Remote Development 0.21.0

これらはインストールされている前提です。

設定ファイルの作成

コマンドパレットを開いて(Shift + Ctrl + p)、Remote-Container: Add Development Container Configuration Files を実行します。

Python3 を選択し、続いて Python のバージョンを選択します。
その後、Node.js をインストールするかどうか表示されますが、今回は必要ないのでチェックを外しました。

OK を押すと、以下のファイルが作成されます。

.devcontainer
├── Dockerfile
└── devcontainer.json

コンテナ起動

画面左下のマークを押し、Reopen in Container を選択するとコンテナが起動します。

拡張機能のインストール

Remote-Containers を使う場合、VSCode の拡張機能もコンテナ用に別途インストールする必要があるみたいです。

devcontainer.json の extensions に記載しておけば、コンテナ作成時に自動的に拡張機能もインストールされるようです。
今回は設定ファイル作成時に Python を選択したので、最初から下記の２つが記載されていました。

 "extensions": [
 "ms-python.python",
 "ms-python.vscode-pylance"
 ],

従って、コンテナを起動した時点で python と pylance は最初から入っているはずなのですが、何故か私の環境ではインストールされていません。

仕方がないので、手動でインストールしました。

手動でのインストール

まず、DEV CONTAINER のところの雲のアイコンをクリックします。

ローカルにインストールされている拡張機能一覧が表示されるので、コンテナ内にインストールしたい拡張機能にチェックを入れます。

インストールが完了した後は一度 VSCode を再起動したほうがよいかと思います。

デバッグを開始する

あとはローカル環境で python のデバッグを行う場合と同じです。

https://kuttsun.blogspot.com/2020/01/vscode-python.html

Devcontainer on ポンコツ地方エンジニアの技術ブログ

Claude Code の認証情報とチャット履歴を devcontainer とホストで共有する

環境

きっかけ

ゴール構成

Claude Code が何を見ているかを把握する

設定する 2 つのマウント

1. .claude / .claude.json のマウント (= コンテナ側ユーザーの home に合わせる)

2. ワークスペースのマウント (= ホスト側の絶対パスに合わせる)

devcontainer.json の例

Dockerfile 側で親ディレクトリを用意しておく

ユーザーは vscode のままでよい

注意点

まとめ

GitHub CLI (gh auth login) で Git の HTTPS 認証を安全にする

環境

きっかけ

ゴール構成

手順

1. 露出したトークンを revoke (最優先)

2. gh をインストール

3. gh auth login で認証

4. remote URL からトークンを除去

5. シェル履歴の残骸を確認

devcontainer での認証共有

補足: SSH 鍵にしないのか

まとめ

ターミナルから GitLab を操る：公式 CLI「glab」導入・活用ガイド

1. インストール方法

2. 初期設定（認証）

3. devcontainer での認証情報共有

4. よく使う基本コマンド集

■ Merge Request (MR) を操作する

■ Issue (課題) を管理する

■ CI/CD パイプラインを確認する

4. gh と glab の主な対応表

5. 自社運用の GitLab (Self-Managed) で使うコツ

まとめ

VSCode の Remote-Containers を起動したときに、マウントのパスに無効な文字が含まれているというエラーが表示された

参考 URL

VSCode + Remote-Containers で python の開発環境を作成する

環境

設定ファイルの作成

コンテナ起動

拡張機能のインストール

手動でのインストール

デバッグを開始する

参考 URL

1. `.claude` / `.claude.json` のマウント (= コンテナ側ユーザーの home に合わせる)

2. `gh` をインストール

3. `gh auth login` で認証

4. `gh` と `glab` の主な対応表