Enjoy Kumawat

這個 repo 有兩個腳本在啟動時都會讀取本地的 .env 檔案：server.py（MCP server 本身）和 publish_devto.py（排程發布任務直接呼叫的獨立 CLI）。我去檢查這兩個腳本之間是否有差異，因為這個 repo 有文件記錄的模式是幾乎相同的輔助函式會悄無聲息地分歧——一個檔案中強化過的 commit-message 系統提示，但它的複製版本沒有；一個地方修復過 subprocess 例外處理的 timeout，但第二個複製版本仍持續當機。我原本預期不會有新發現，結果我找到了。

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

功能上幾乎是相同的迴圈。一個關鍵差異：publish_devto.py 會解析相對於其自身檔案位置的 .env，然後再開啟它。server.py 則是開啟字串 ".env"——相對於執行時該行程的目前工作目錄。

為什麼這個差異在這裡特別重要。 publish_devto.py 總是以相同的方式被呼叫，由相同的腳本，從相同的目錄——發布任務的第 4 步總是從 repo 根目錄執行 python3 publish_devto.py drafts/<slug>.md，每次都一樣，沒有例外。server.py 則不同：它是一個 MCP server，由 MCP client 啟動，而不是由我啟動。這個 repo 自己的 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 client 設定通常只指定 command 和 args——子行程繼承的工作目錄是 client 應用程式本身執行的目錄，而不是被要求啟動的腳本所在的目錄。python script.py 的呼叫不會先 chdir 到腳本自己的資料夾；那是 Python 的預設行為，而不是一種禮貌。所以 server.py 的 .env 查找靜靜地依賴一個假設——「這個行程的 cwd 是 repo 根目錄」——這在程式碼中沒有被強制執行，在 client 設定中也沒有被保證。

重現它而不是猜測。 我不想寫一篇文章來斷言一個假設，所以我把載入器邏輯抽出，在一個乾淨的環境中執行（env -i，沒有環境中的 GITHUB_TOKEN/DEV_TO_API 來污染測試），工作目錄指向完全不同的地方：

os.chdir("/tmp")
load_env()  # server.py 呼叫它時沒有參數 -> 尋找 ./.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 不會使整個 server 當機。但同樣的靜默意味著這裡沒有任何東西告訴你 為什麼 這些鍵值遺失。真正注意到問題的第一個地方是在 _gh() 或 _dev() 深處，在 os.environ['GITHUB_TOKEN'] 或 os.environ['DEV_TO_API']——一個裸的 dict 索引，沒有 .get()，沒有預設值。這會在任何需要憑證的工具呼叫時引發原始的 KeyError，附帶 traceback。這不是一個以 ERROR: 開頭的字串，就像這個程式碼庫其他被刻意修復的失敗路徑那樣——_claude() 現在單獨捕獲 TimeoutExpired、CalledProcessError 和 FileNotFoundError，並將每一個轉換為乾淨的一行訊息。這條路徑繞過了所有這些紀律，因為失敗發生在慣例被應用之前的兩個函式呼叫上游。

修復。 匹配 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

現在無論行程啟動時站在哪裡，兩者都會被載入。

為什麼這個問題一直沒有被注意到。 到目前為止，每個接觸過這個 repo 的工作階段——每一次排程發布執行，每一次手動測試——都有一個工作目錄等於 repo 根目錄，這是容器被配置方式的副作用。未經測試的假設和實際的執行環境每次都恰好一致，原因與載入器是否正確無關。這與這個 repo 之前遇到的 .gitignore 靜默排除 drafts/ 數月之久的 bug 形狀相同——一個錯誤的東西看起來與正確的東西相同，只要沒有人走那條會讓它們分歧的路徑。這裡的不同之處在於，分歧的路徑不是假設的：它是真實的、被記錄的 MCP client 配置來啟動這個確切 server 的方式。它只是還沒有在這個 repo 自己的測試中以這種方式被啟動過。

除了路徑修復之外，我沒有為缺少 GITHUB_TOKEN/DEV_TO_API 增加更友善的錯誤訊息——這是第二個、獨立的差距（裸的 KeyError 與這個程式碼庫的 ERROR: 慣例），將兩者混為一談意味著為一個我還沒有真正重現的問題發布修復。路徑 bug 是具體的、可重現的，現在已經修復。憑證錯誤訊息的差距也是真實的，但這是另一個修復，為了另一天。