Claude Code 在終端機中執行，但對執行環境相依套件、目錄權限、金鑰存放與企業 Proxy 都有要求。本文依實際落地順序說明本機要準備什麼，以及團隊之間如何共用設定。
Claude Code 是終端機裡的工具，安裝完成後輸入一行指令就能使用，所以很多人會把注意力全放在網路上。真正容易卡住的通常是另外幾件事：執行環境版本是否正確、專案目錄有沒有寫入權限、金鑰放在哪裡、公司 Proxy 要怎麼走，以及同事之間如何共用同一份設定。
先對齊執行環境與相依套件
先查看官方文件目前要求的執行環境版本，照文件指定的版本安裝，不要拿剛發佈幾天的新版本直接嘗試。套件管理器也跟著團隊標準走，npm、pnpm、yarn 混著用時，lock 檔很容易互相衝突。git 和基本命令列工具都是必要條件，因為這類工具需要讀取 repository、執行指令、跑測試，少了任何一環都會立刻報錯。
安裝完成後，先在空目錄中把三件事跑通：能讀檔案、能改檔案、能跑測試。小目錄裡的環境問題很快就會暴露；混在業務程式碼裡排查，成本會高很多。
專案目錄、權限與邊界
不要在使用者家目錄或整顆硬碟的根目錄下啟動它。給它一個明確的 repository 根目錄，把讀寫範圍限制在專案內；真的需要更大範圍時，使用一次性授權，而不是長期開放。
提交前先看一下 .gitignore。本機產生的快取、日誌、暫存腳本都要擋在版本庫外。團隊裡最容易出問題的，往往不是程式碼寫錯，而是有人順手把本機除錯產生的敏感檔案一起提交上去。
金鑰與憑證怎麼放
API key、存取 token 這類敏感資訊，應透過環境變數或作業系統的憑證管理機制提供，不要寫進原始碼、設定檔或腳本註解。.env 本身也要放進 .gitignore，repository 裡只保留一份用來說明各欄位含義的範例檔案。
個人憑證與團隊憑證分開管理。幾個人共用同一個 key，出問題時就很難查清楚是誰在使用。輪替節奏要事先定好：定期更換、成員離職當天更換、疑似洩漏就立刻更換。發現洩漏時，先撤銷再調查，不要先刪日誌。
與企業 Proxy、網路環境配合
在公司網路裡使用這類工具，麻煩通常不在能不能連線，而在 Proxy 與憑證。企業閘道如果做 TLS 攔截，工具可能因為不信任憑證鏈而直接報錯。這種情況應向 IT 取得內部根憑證，安裝到正確的信任位置，而不是暫時關掉驗證。
登入流程會喚起瀏覽器，所以命令列與瀏覽器最好走同一個出口，而且這個出口要固定、穩定、可控。三個條件少一個，就容易出現反覆重新登入或跳出 CAPTCHA 驗證。頻繁切換節點比固定使用單一節點更容易觸發檢查，因為後者看起來更像長期使用的使用者。
出口到底有沒有生效，驗證方式很直接：讓命令列帶上 Proxy 參數，請求一次 IP 查詢服務。
curl -x http://127.0.0.1:7897 https://ipinfo.io
顯示的位址應該是預期的那一個。瀏覽器的時區和語言也最好與出口地區一致，不要一邊顯示北美、一邊卻是 UTC+8。
團隊之間怎麼共用設定
可以共用的是結構，不是金鑰。把工作目錄規範、Proxy 分流規則、允許執行的指令範圍、程式碼風格限制寫進 repository 內一份可提交的設定檔；金鑰則在各自的機器上透過環境變數注入。
新成員照著文件走一遍就能啟動，不需要逐一詢問同事。團隊同時存在多個身分或多套環境時，也可以使用 PurpleMark 固定每個環境的瀏覽器狀態，之後就能追查某個登入動作發生在哪一套環境中。
收尾
這類工具出問題，多半不是它自己的 bug，而是前置條件沒有對齊。執行環境與相依套件、目錄權限、金鑰位置、Proxy 出口、設定共用，這五件事先在小專案上花時間理順，後續就能省下反覆排查的成本。
