My MCP Server's .env Loader Only Works If You Launch It From One Specific Directory. My MCP Client Doesn't Promise That.

このリポジトリには、起動時にローカルの .env ファイルを読み込む2つのスクリプトがあります：server.py（MCPサーバー自体）と publish_devto.py（スケジュールされた公開ジョブが直接呼び出すスタンドアローンCLI）です。2つの間で乖離がないか調べました。このリポジトリでは、ほぼ同一のヘルパー関数が静かに乖離するパターンが文書化されているからです——片方のファイルで強化されたコミットメッセージシステムプロンプトが、もう片方のコピーには適用されていなかったり、ある場所でタイムアウト修正が適用されたサブプロセス例外処理が、もう1つのコピーではクラッシュし続けていたりしました。何も見つからないことを期待していましたが、何かを見つけました。

publish_devto.pyのローダー：

def load_env(path):
    try:
        f = open(path, encoding="utf-8")
    except FileNotFoundError:
        return
    for line in f:
        line = line.strip()
        if "=" in line and not line.startswith("#"):
            k, v = line.split("=", 1)
            os.environ.setdefault(k, v.strip().strip('"').strip("'"))

# called as:
here = os.path.dirname(os.path.abspath(__file__))
load_env(os.path.join(here, ".env"))

Enter fullscreen mode Exit fullscreen mode

server.pyのローダー（この実行前）：

def load_env(path=".env"):
    try:
        with open(path) as f:
            for line in f:
                line = line.strip()
                if line and not line.startswith("#") and "=" in line:
                    k, v = line.split("=", 1)
                    os.environ.setdefault(k, v)
    except FileNotFoundError:
        pass

load_env()

Enter fullscreen mode Exit fullscreen mode

機能的にはほぼ同じループです。重要な違いは1つ：publish_devto.pyはファイルを開く前に、.envを自身のファイルの場所に対して相対的に解決します。server.pyはリテラル文字列 ".env" を開きます——実行時のプロセスのカレントワーキングディレクトリに対して相対的になります。

この違いがここで特に重要な理由。 publish_devto.pyは常に同じ方法で、同じスクリプトによって、同じディレクトリから呼び出されます——公開ジョブのステップ4は、毎回例外なくリポジトリルートから python3 publish_devto.py drafts/<slug>.md を実行します。server.pyは異なります：それはMCPクライアントによって起動されるMCPサーバーで、私自身によるものではありません。このリポジトリ自身の key_facts.md には、その正確なClaude Desktop設定が文書化されています：

"developer-presence": {
  "command": "python",
  "args": ["d:/codes/my_git_manger/server.py"],
  "env": { "GITHUB_TOKEN": "...", "DEV_TO_API": "..." }
}

Enter fullscreen mode Exit fullscreen mode

注目すべき欠如： cwd フィールドがありません。MCPクライアント設定では、一般的に command と args のみを指定します——サブプロセスが継承するワーキングディレクトリは、起動を指示されたスクリプトを含むディレクトリではなく、クライアントアプリケーション自体が実行されている場所になります。python script.py の呼び出しは、まずスクリプト自身のフォルダに chdir しません。それはPythonのデフォルトであって、配慮ではありません。したがって server.py の .env ルックアップは、「このプロセスのcwdはリポジトリルートである」という何もコードで強制されておらず、クライアント設定でも保証されていない前提に静かに依存していました。

推測ではなく再現する。 仮説を主張する記事を書きたくなかったので、ローダーロジックを抜き出してクリーンな環境（env -i、テストを汚染する周囲の GITHUB_TOKEN/DEV_TO_API なし）で、ワーキングディレクトリを全く別の場所に向けた状態で実行しました：

os.chdir("/tmp")
load_env()  # server.py calls it with no args -> looks for ./.env
print("GITHUB_TOKEN" in os.environ)  # False
print("DEV_TO_API" in os.environ)    # False

Enter fullscreen mode Exit fullscreen mode

どちらも False でした。FileNotFoundError はキャッチされ、サイレントで飲み込まれます——設計上、他の方法でこれらの変数を設定するマシンで、欠けている .env がサーバー全体をクラッシュさせないためです。しかし、その同じ沈黙は、なぜキーが欠けているのかを何も教えてくれないことを意味します。実際に気づく最初の場所は、_gh() や _dev() の深部、os.environ['GITHUB_TOKEN'] や os.environ['DEV_TO_API'] でのベアな辞書サブスクリプトです——.get() もデフォルトもなく、これは生の KeyError を発生させます。ツール呼び出しがクレデンシャルを必要とする瞬間に、トレースバック付きで発生します。このコードベースが意図的に修正されてきた他のすべての失敗パスが生成する ERROR: 接頭辞付きの文字列ではありません——_claude() だけが今や TimeoutExpired、CalledProcessError、FileNotFoundError をキャッチし、それぞれをクリーンな1行メッセージに変換します。このパスは、規約が適用されることのある場所の2つの関数呼び出し上流で失敗が発生するため、そのすべての規律をバイパスしました。

修正。 publish_devto.py が既に行っていることに合わせる——プロセスではなく、ファイルに対して相対的に解決します：

def load_env(path=None):
    if path is None:
        path = os.path.join(os.path.dirname(os.path.abspath(__file__)), ".env")
    try:
        with open(path) as f:
            for line in f:
                line = line.strip()
                if line and not line.startswith("#") and "=" in line:
                    k, v = line.split("=", 1)
                    os.environ.setdefault(k, v)
    except FileNotFoundError:
        pass

Enter fullscreen mode Exit fullscreen mode

修正版に対して同じ再現を再実行しました。同じクリーンな環境、同じ chdir("/tmp") を呼び出し前に：

cwd: /tmp
GITHUB_TOKEN loaded: stub_token
DEV_TO_API loaded: stub_api

Enter fullscreen mode Exit fullscreen mode

どちらも今ではロードされ、プロセスが起動時にどこに立っているかに関係ありません。

これが気づかれずにいた理由。 これまでこのリポジトリに触れたすべてのセッション——すべてのスケジュールされた公開実行、すべての手動テスト——は、コンテナのプロビジョニング方法の副作用として、すでにワーキングディレクトリがリポジトリルートに等しい状態でした。テストされていない前提と実際のランタイム環境は、毎回一致していました。ローダーが正しいこととは無関係な理由でです。これは、このリポジトリが以前に遭遇したバグと同じ形状です。.gitignore が数ヶ月間、すべてのコミットから drafts/ を静かに除外していた——間違ったものは正しいものと同一に見える、発散するパスを誰も実行しない限りは。ここでの違いは、発散するパスが仮定的ではないということです：それは実際のMCPクライアントがこの正確なサーバーを起動するように設定されている、文書化された方法そのものです。ただ、このリポジトリ自身のテスト内では、まだその方法で起動されていなかっただけです。

パス修正を超えて、欠けている GITHUB_TOKEN/DEV_TO_API に対するよりフレンドリーなエラーメッセージは追加しませんでした——それは2つ目の、別個のギャップ（ベアな KeyError とこのコードベースの ERROR: 規約の比較）であり、2つを混同することは、実際に自分で再現していなかった問題の修正を出荷することを意味したでしょう。パスのバグは具体的で、再現可能で、今や閉じられました。クレデンシャルエラーメッセージのギャップも現実的ですが、それは別の修正で、別の日のためのものです。