本当は怖いHPC & AI

HPC / AI屋さんの外部記憶装置。メモ書き。

Ghosttyでエスケープ文字列が入力されてしまう問題

Ghosttyを使っているとき、SSH経由でBashやZshを使っていると、例えば Ctrl + I で、以下のようなエスケープシーケンスが間違って文字列として入力されてしまいます。

5;5u

なぜこのようなことが起こるのかというと、Ghosttyは、Terminalでキーボードイベント(キー押下など)を送信するプロトコルとして CSI u (Kitty Keyboard Reporting Protocol) を実装しているからです。これは比較的新しいプロトコルで、従来の Bash や Zsh などのソフトウェア、あるいは GNU Readline のようなライブラリは、まだこの新しいプロトコルに未対応です。

CSI u プロトコルについては、ここでは深入りしませんが、Ghostty ではこのプロトコルを無効化する方法は現時点では存在しないようです。ですので、今回は困ったときに個別のキーコードを全て無効化する方向で、Ghostty の設定ファイルを書くことにします。

keybind = ctrl+i=text:\x09

これで Ctrl+I で Tab キーが入力されるようになりました。

VSCodeによるk8s pod へのアタッチ(初回)に異常に時間がかかる問題

(この文章は人間が書いています。トラブルシューティング・技術的な内容についてはChatGPTの支援を受けています)

VSCodeのKubernetes拡張を使うと、Kubernetes上のPodをDev Containerとして使うことができます。kubernetesエクステンションから、Workloads → Pods → Pod名 を右クリックして "Attach Visual Studio Code" を実行するとアタッチできます。

しかし、私の環境だと問題がありました。 Connecting to Dev Container (show log): Installing server という表示とともに、刺さってしまいます。

ChatGPTの助けを借りて調べてみました。

まず、VSCodeが何をしようとしているのかを説明しておきましょう

  • DevContainer上で、VSCodeを支援するバイナリを送り込む
  • そのプログラムを起動して、いろいろなコーディング支援機能を実行する

どうやら、この「VSCodeを支援するバイナリを送り込む」ところで送信がうまくいかず刺さってしまっているようです。

可能性としては、

  • ツールの互換性(特に tar/dd/gzip などのGNU系ツールと、MacのBSD系ツールの互換性問題)で齟齬が生じ、データ転送ができてないのに永遠に待ってしまっている
  • 何かの理由で、単純にデータ転送が異常に遅い
  • その他の原因

が考えられます。ログを見る限りツールの互換性は大丈夫っぽかったので、「転送速度が遅い」可能性を調査しました。

$ NS=<namespace>
$ POD_NAME=<pod name> 
head -c $((80*1024*1024)) </dev/zero \
| kubectl exec -i $POD_NAME -n $NS -- sh -lc 'dd of=/dev/null bs=1M status=progress'
Defaulted container "main" out of: main, installer (init)
1179648 bytes (1.2 MB, 1.1 MiB) copied, 64 s, 18.3 kB/s

理由は不明ですが、転送が極めて遅いことがわかった。なので、あらかじめ必要なバイナリをPod内に手動で配置してしまえば良さそうです。

具体的な手順は以下のようになります

  • VSCodeがDevContainer(Pod)へ送り込むバイナリファイル自体を入手する
  • それをPod内へ送り込む
  • 適切な場所・ファイル名で保存する

というわけで、以上の操作をシェルスクリプトにまとめました。このスクリプトをkubectlがインストールされているローカル側のPCから実行すればOKです。

#!/bin/bash

VSCODE_COMMIT_HASH=$(/Applications/Visual\ Studio\ Code.app/Contents/Resources/app/bin/code --version | head -n 2 | tail -n 1)
POD=$1

DT=$(date '+%Y%m%d_%H%M%S')
TMP_NAME=vscode-server-$DT.tar.gz

echo VSCODE_COMMIT_HASH=$VSCODE_COMMIT_HASH

kubectl exec -i $POD -c main -- bash <<EOS
echo test
cd /tmp
mkdir -p $VSCODE_COMMIT_HASH
cd $VSCODE_COMMIT_HASH
curl -L "https://update.code.visualstudio.com/commit:$VSCODE_COMMIT_HASH/server-linux-x64/stable" -o $TMP_NAME
tar -xf $TMP_NAME
VSCODE_DIR=\${HOME}/.vscode-server/bin/${VSCODE_COMMIT_HASH}/
mkdir -p \$VSCODE_DIR
cp -a vscode-server-linux-*/* \$VSCODE_DIR/ && chmod -R u+rwX,go-rwx \${HOME}/.vscode-server

EOS

これで無事に成功しました。VSCodeがアップデートされるたびに、このスクリプトでのファイル転送が必要になりますが。

MacでClaude Codeをコンテナ上で実行する準備をした

(この記事は人力で書いていますので雑で簡略ですがご了承ください)

Macで最近サポートされたContainerization Frameworkを使って、Claude Codeを動作させてみました

コンテナのビルドまではこちらの記事通りでOKでした。

zenn.dev

Claude Codeの動作確認

❯ container run --rm claude-code claude --version
1.0.92 (Claude Code)

ここまでOK.

このままClaude Codeを実行すると、私の環境では

OAuth error: Failed to start OAuth callback server: getaddrinfo EAI_AGAIN localhost

OAuth error: Failed to start OAuth callback server: getaddrinfo EAI_AGAIN localhost

というエラーが出てしまいました。おそらくコンテナの中のネットワーク設定がおかしくなっているようです。Dockerと違い、MacOSのContainerization Frameworkはネットワークの設定はデフォルトで --network=host 相当になるらしいので、よくわかりません。今回はちょっとゴリ押しで解決することにしました

まず、Container環境の外で Claude Code をログインしておきます。そしてcontainer imageビルド時に、 $HOME/.claude.json をコンテナ内の /home/node/ にコピーしておきます。さらに、https://console.anthropic.com/settings/keys からAPI Keyを発行して、 ANTHROPIC_API_KEY 環境変数として指定してcontainerを起動します。

container run -e ANTHROPIC_API_KEY=$ANTHROPIC_API_KEY --rm -it -v $PWD:/workspace claude-code:latest zsh

これでひとまず container 内でclaudeを起動できました