Kimi Code CLIを使い始める：インストール、ログイン、最初の10分、3つの承認モード、設定ファイルを公式ドキュメントで確かめる

この記事は、公式ドキュメントを2026年10月24日に読んでまとめたものです。この記事は、実際に使って確かめた記録ではありません。運営者はKimiを入れていますが、使い心地はこの記事には書いていません。コマンド、フラグ、設定のキー、画面の項目名は、公式ページに書かれているとおりに写したもので、動作確認はしていません。公式ページは要約として取得したため、読み切れていない所は「読めていない」「確認できず」と書いています。多くのページには日付が付いておらず、日付が分かるのは更新履歴（CLI v2.3.0は2026-10-21）などに限られます。バージョンや上限は変わることがあります。

先に結論

• まず決めること。 ①どの入口でログインするか（会員のOAuthか、APIキーか）、②承認のモードを何で始めるか、③作業するフォルダを何にするか、の3つです。
• 承認は、既定のまま始める。 既定の「Always Ask」は、ファイルの変更もコマンドの実行も1回ずつ確認します。公式は --yolo について、信頼できる作業フォルダでだけ使うよう書いています。
• 「Never Ask」は別物。 質問もしない完全な無人のモードで、機密ファイルへのアクセスと危険なコマンドの確認も付きません。公式のこのモードの説明に、使う場所を限る注意書きがあるかは、読んだ範囲では見つかりませんでした（--yolo の警告は読めました）。
• 設定ファイルは、ユーザー単位が中心。 ~/.kimi-code/config.toml が本体で、プロジェクトの中に置けるのは .kimi-code/local.toml（追加フォルダの指定）と .kimi-code/mcp.json（MCPの設定）などです。
• 鍵はファイルか api_key_env で渡す。 公式は、APIキーをシェルの環境変数から自動では読まない、と繰り返しています。

前提：用語をそろえる

• TUI：ターミナルの中に出る、対話型の画面。kimi を引数なしで起動すると開きます。公式は、この画面を「完全に対話的」と書いています。
• スラッシュコマンド：入力欄に / から始めて打つ内蔵の命令（/login、/model、/plan など）。
• 承認（パーミッション）：ファイルの変更やコマンドの実行の前に、CLIが人に許可を求める仕組み。
• Plan モード：ファイルを変える前に計画を出し、承認を待つ状態。
• OAuth（デバイスコード方式）：画面に出るリンクを別の端末で開き、サインインして、出てきたコードを入れて許可する方式。
• API キー：Open Platform（platform.kimi.ai など）で作る鍵。課金は従量で、会員とは別です（前のガイドに書いたとおり）。
• セッション：1回の作業の記録。再開や複製（fork）ができます。
• 旧版（kimi-cli）：Python製の前の版。公式GitHubでアーカイブされたと、02で書きました。

入れる：3つの方法

公式の「Getting started」は、スクリプト（推奨）とnpmの2通りを挙げています。画面の見た目のために、公式は、24ビットカラーと合字に対応した端末（KittyやGhosttyなど）を勧めています。

公式の更新履歴には、Homebrewでの導入に対応した、という記載（0.12.0、2026-06-09）もありますが、コマンドは読めていません。

確かめ方は kimi --version（短縮は -V）です。README は、新しいシェルで確かめるよう書いています。macOSでは、初回の起動が遅いことがあり、公式のFAQは、新しいプログラムをOSが検査するためで、終わるまで待つか、端末アプリを「システム設定」→「プライバシーとセキュリティ」→「開発者ツール」に加える、と説明しています。

僕らの見立てです。curl ... | bash や irm ... | iex は、ネットから取ってきたスクリプトをそのまま実行する形です。公式が、スクリプトの中身を先に読むよう案内しているかは、読んだ範囲では見つかりませんでした。気になる場合は、URLを先にブラウザで開いて内容を読む、または npm を使う、という選び方があります。

ログイン：どの入口を選ぶか

プロジェクトのフォルダで kimi を起動し、初回は入力欄に /login と打つと、接続先の選択画面が開きます。公式は2つを挙げています。

ほかの提供元（Anthropic、OpenAI、Googleなど）は、/login ではなく、~/.kimi-code/config.toml を編集して設定する、と書かれています。ログアウトは /logout で、現在の認証情報が消えます。TUIを開かずに、シェルから kimi login でデバイスコードのログインもできます（成功で終了コード0、取り消しや失敗で1）。

会員で使うときの前提。 公式の「Membership Benefits」は、Kimi Code が使えるのは、新しい名前のプランでは Plus 以上、旧名では Andante 以上と書き、Go には含まれないとあります。5時間の回転窓の上限は全員にあり、週ごとの上限は旧プランだけです。月の枠は、Kimiの会員全体と共有されます。ログインした端末とAPIキーは、同じ枠を使います。30日を超えて使わなかった端末は、紐づけが外れ、/login をやり直すと戻ります。枠の確認は、Kimi Codeのコンソール、購読のページ、CLIの /usage です。

地域とURL。 公式のFAQは、次の表のように、中国と海外でURLを分けています。

エラー表には、「Kimi Codeの鍵とOpen Platformの鍵、またはそれぞれのベースURLを混ぜると401になりやすい」と書かれています。環境変数の説明にも、OAuthのあとの KIMI_CODE_BASE_URL（既定 https://api.kimi.com/coding/v1）と、APIキー用の KIMI_BASE_URL（既定 https://api.moonshot.ai/v1）は別物で、取り違えないように、という注意があります。CLIがどの条件で中国側と海外側を選ぶかは、読んだ範囲では書かれていませんでした。

最初の10分でやること

ここは、公式の「Getting started」と「Interaction and input」に書かれている手順を、順番に並べたものです（並べ方は僕らの整理です）。

1. 入れる。 上の表のどれかで入れ、kimi --version で確かめる（2分）。
2. 試す場所を決める。 公式の指定ではなく、僕らの整理です。いきなり大事なリポジトリではなく、gitで管理した小さなフォルダで始めます。理由は後ろに書きます。
3. 起動して接続する。 cd your-project のあと kimi。入力欄に /login と打ち、OAuthかAPIキーを選ぶ。
4. 読むだけの質問から。 公式の例は「このプロジェクトのディレクトリ構成を見て、各ディレクトリの役割を簡単に説明して」です。読み取りは自動で実行されます。
5. 今の状態を見る。 /status が、版、モデル、作業フォルダ、承認のモードなどを出します。/usage はトークンの使用量、文脈の消費、枠を出します。
6. 小さな変更を頼む。 公式の例は、src/utils に文字列をkebab-caseにする関数と、そのテストを足す依頼です。ファイルの変更とシェルの実行は、確認の画面が出ます。
7. 確認画面を読む。 選ぶには、矢印キーと Enter、または数字キーです。公式のキー一覧では Ctrl-E で差分やファイルのプレビューを広げられ、Esc、Ctrl-C、Ctrl-D で拒否です。選択肢のうち「このセッションでは同じ種類の呼び出しを自動承認する」があります。数字が何に対応するかは、読んだ範囲では書かれていませんでした。
8. Plan モードを触る。 Shift-Tab（または /plan）で入ります。計画が出るまでファイルは変わらず、計画の承認が要ります。/plan on、/plan off で状態を指定でき、/plan clear で今の計画を消せます（公式のコマンド表）。
9. やり直し方を知る。 /undo はプロンプトを取り消しますが、公式は「コードの変更は元に戻らない」と書いています。Esc を2回押すと、取り消しの選択画面が開きます。
10. 終わり方。 /exit、またはアイドル中に Ctrl-C を2回、入力欄が空なら Ctrl-D。次に続けるなら kimi -c（同じフォルダの直前のセッションを再開）です。

作業の途中で別の案を試したいときは、/fork が、今の会話の履歴を引き継いだ新しいセッションを作ります（公式の説明では、今のセッションに留まります）。OAuthやAPIキー以外の提供元を足すときは、/provider で、設定済みの提供元の確認、追加、削除ができる対話画面が開きます。

そのほか、公式が挙げている入力のコツです。@ でファイルのパスを補完し、! を空の入力欄で打つとシェルモードに入ります（コマンドの出力は会話の文脈に入ります）。Enter が送信、改行は Shift-Enter か Ctrl-J です。実行中に言い足したいときは Ctrl-S で、動いている最中の回に差し込めます。/help で一覧が出ます。

僕らの見立てです。/undo が会話だけを戻し、ファイルを戻さないのなら、変更の巻き戻しはgitに頼るのが確実です。試す前に git status がきれいか、確かめておくと安心です。公式がgitの利用を勧めている文は、読んだ範囲では見つかっていません。

承認と権限：3つのモードを見分ける

公式の「Interaction and input」と更新履歴によると、モードは3つで、名前は、更新履歴では0.41.0（2026-09-04）、What's New では0.40.0（2026-09-02）で「Always Ask」「Ask When Needed」「Never Ask」に付け替えられた、と書かれています（版は公式の中で食い違っています）。旧名は Manual、YOLO、Auto で、設定ファイルや旗には旧名が残っています。

/yolo と /auto は、公式のコマンド表では、モードの一覧を開いて、それぞれを選んだ状態にするものと説明されています。そのため、選択の確認が要る場合があります。モードの切り替えだけを開くコマンドは /permission（単数）です。/permissions や /trust は、コマンド表に載っていませんでした。

公式が出している警告。

• kimi --yolo は、ファイルの書き込みやシェルの実行を含む通常のツール呼び出しで、人の承認を飛ばします。公式は「信頼できる作業フォルダでだけ」使うよう書いています。/yolo の説明にも、リスクを理解してから使うよう警告があります。
• Planモードの終了の承認は、/yolo では飛ばせません。ただし「Never Ask」では、計画の承認も自動で通り、画面に「Auto-approved」と出ます。
• 危険なコマンドの確認（ガード）は、「Always Ask」と「Ask When Needed」で働きます。「Never Ask」では、これらのコマンドは止まらずに実行される、と公式にあります。
• 「Ask When Needed」や「Never Ask」に切り替えるとき、ファイルが直接変更・削除されうる、と警告が出るようになった、と更新履歴（0.41.0、Web版の項目）に書かれています。

更新履歴で分かる、既定値と挙動の変化。 古い解説と食い違いやすい点です。

「Ask When Needed」の説明は「危険なコマンドは確認」ですが、更新履歴どおりなら、静的に解析できないコマンドは確認の対象外です。何が「解析できない」かの定義は、読んだ範囲では見つかっていません。このモードを「安全な自動」と受け取らない方がよい、というのが僕らの見立てです。

ルールで決める：[[permission.rules]]

モードが「基準」なら、ルールは個別の例外です。公式の「Configuration files」の例は次のとおりです。ルールは上から順に照合され、最初に当てはまったものが使われます。

[[permission.rules]]
decision = "allow"
pattern = "Read"

[[permission.rules]]
decision = "allow"
pattern = "Grep"

[[permission.rules]]
decision = "deny"
pattern = "Bash(rm -rf*)"

[[permission.rules]]
decision = "ask"
pattern = "Bash"

注意点です。AgentSwarm、MCPのツール、独自のツールは、名前だけで照合され、引数のパターンは使えません。一方、ツール一覧のページは、Bash(command-pattern) や Read(path-pattern) の書き方は、そのページには書かれていない、としています（設定ページの例には Bash(rm -rf*) が出ています）。パターンの照合規則（ワイルドカードの扱いなど）の説明は、読んだ範囲では見つかりませんでした。書いたルールが効くかは、安全な場所で確かめるのが安全、というのは僕らの見立てです。

順序で結果が変わる（僕らの整理です）。 「最初に当てはまったものが使われる」という公式の説明を、上の例に当てはめた読み方です。例のとおり deny の Bash(rm -rf*) を ask の Bash より上に置くと、rm -rf で始まるコマンドは拒否され、ほかのBashは毎回確認になります。逆に ask の Bash を先に書くと、すべてのBashが先にそこで当てはまるので、あとの deny には届かないはずです。拒否は、広い ask や allow より上に書く、と覚えておくと安全側に倒せます。動作は確かめていないので、安全な場所で試してください。

「許可を増やす」もう1つの道。 公式の「Common use cases」は、安全だと分かっているバッチ作業には --yolo や /yolo を使えるが、そうする代わりに、特定のツールだけを事前に許可するルールを設定ファイルに足す道もある、と書いています。「Always Ask」のまま、よく使う読み取り系だけを allow にしていく、という進め方に当たります。

ツールごとの承認。 公式のツール一覧では、Read、Grep、Glob は自動で通り、Write、Edit、Bash は承認が要ります。TaskStop、CronCreate、CronDelete も承認が要ります（AgentSwarm は、swarm モードの外では承認が要り、中では自動承認、と書かれています）。Grep と Glob は、.env や秘密鍵のような機密ファイルを自動で除外する、とあります。

設定ファイルに書かない、その場だけの指定。 kimi --plan（計画から開始）、kimi --yolo、kimi --auto。再開のときに付けると、保存されていたモードを上書きします（kimi --continue --auto など）。--yolo と --auto は同時に指定できません。

dangerous_command_guard

設定の [permission] の中にあり、既定は true です。

[permission]
dangerous_command_guard = false

false にすると、危険コマンド、機密ファイル（.env、id_rsa など）、gitの制御パスの組み込みの確認が、すべて止まります。環境変数 KIMI_CODE_DANGEROUS_COMMAND_GUARD=false による上書きもある、と設定ファイルのページにあります（ファイルとの優先順位は読めていません）。公式の警告は、コマンドをエージェントの外で制限している環境でだけ使うこと、です。なお、Read、Write、Edit が秘密のファイルに触れるのを止める「ハードブロック」は、この設定を false にしても残る、と書かれています。

設定ファイル：どこに、何を書くか

公式の「Configuration files」と「Data locations」の整理です。形式はTOML、キー名はsnake_caseです。

場所は、環境変数 KIMI_CODE_HOME で移せます。すると、設定、セッション、ログ、OAuthの認証情報、Kimi専用のSkills、全体用の AGENTS.md が、新しい場所に移ります。例外として、汎用の ~/.agents/skills/ と ~/.agents/AGENTS.md は、実際のホームの下に残ります。

config.toml の主なキーは次のとおりです（公式の表から抜粋）。

公式は、. を含むキーは引用符で囲むよう注意しています（例：[models."gpt-4.1"]）。kimi doctor は、config.toml と tui.toml を書き換えずに検査し、問題があれば終了コード1を返します。壊れた tui.toml は、既定値に戻って通知が出ます。

公式の例（抜粋）。 起動時に作られる設定の形です。モデルの部分は、省略しています。

default_model = "kimi-code/k3"
default_permission_mode = "manual"
default_plan_mode = false
telemetry = true

[providers."managed:kimi-code"]
type = "kimi"
base_url = "https://api.kimi.com/coding/v1"
api_key = ""

[thinking]
enabled = true
effort = "high"
keep = "all"

[loop_control]
max_attempts_per_step = 10
reserved_context_size = 50000

[[hooks]]
event = "PreToolUse"
matcher = "Bash"
command = "node ~/.kimi-code/hooks/check-bash.mjs"
timeout = 5

[[hooks]] の項目（公式の「Hooks」より）。 上の例の [[hooks]] は、ツールを呼ぶ前などに自分のコマンドを走らせる設定です。使える項目は次の4つだけで、ほかのキーを書くと設定ファイルが読み込めなくなる、と書かれています。

上の抜粋は timeout = 5 と書いていますが、省略すれば30秒です。5秒で終わらない処理を載せると、時間切れになります。時間切れやエラーのときは、CLIは作業を止めず、処理を通します（フックの失敗は許可として扱われる）。

試す用の隔離環境：設定を汚さずに触る

公式の「Config overrides」は、「Isolated test environment」の例として、次の1行を挙げています。

KIMI_CODE_HOME="$PWD/.kimi-sandbox" kimi

この1回の起動だけ、設定、セッション、ログ、OAuthの認証情報の置き場が、カレントの .kimi-sandbox に変わります。本番の ~/.kimi-code/ を汚さずに、承認のモードやルールを試せる、という使い方です（動作は確かめていません）。ただしログインはこの置き場の中で別に要り、試し終えたあとは .kimi-sandbox を消せば片付きます（僕らの整理です）。

鍵の渡し方：いちばん間違えやすい所

api_key と api_key_env は、どちらか一方だけを設定します。両方、または api_key_env と oauth の組み合わせは、設定の衝突になります。優先順位は、api_key または api_key_env、次に env 表で、全部なければ起動に失敗します。oauth はログインの処理が書く欄で、手で編集しないよう書かれています。

そして、環境変数の一覧ページに、強い警告があります。シェルで export KIMI_API_KEY=... と書いても何も起きない、という趣旨です。ただし、KIMI_MODEL_* の系列（一時的なモデルを作る）と api_key_env は、シェルから読む、明示的な経路として例外です。Google系の GOOGLE_APPLICATION_CREDENTIALS も、SDKが直接読む例外です。

優先順位

公式の「Config overrides」は、設定の元が一本の階段ではないと説明しています。普通の実行時の指定（モデルの別名、Plan、承認のモード、Skillsのディレクトリ）は、①コマンドラインの旗、②ユーザーの設定ファイルの順です。環境変数は、一部の項目だけを明示的に上書きします（このページの例は KIMI_CODE_BACKGROUND_KEEP_ALIVE_ON_EXIT。ほかに、環境変数のページには KIMI_LOOP_MAX_STEPS_PER_TURN、設定ファイルのページには KIMI_CODE_DANGEROUS_COMMAND_GUARD が載っています）。テレメトリは、KIMI_DISABLE_TELEMETRY が真なら、設定ファイルで true でも止まる、と書かれています。

ワークスペースの信頼

更新履歴（2.1.0、2026-09-23）は、プロジェクトのローカルな設定は、そのワークスペースを信頼してから適用される、と書いています。MCPのページには、未信頼のフォルダにプロジェクト用のMCPサーバーがあると、信頼ダイアログに各サーバーの起動方法（コマンドと引数、またはURL）が並び、確認してから進めるように、と書かれています。ダイアログの既定は「このフォルダを信頼する」です。信頼するまで、そのMCPサーバーは無効です。

• stdioのMCPサーバーは、セッションの開始時にローカルのコマンドを実行します。公式の警告は、信頼できるリポジトリでだけ有効にすること、です。
• kimi -p のようなヘッドレスの実行では、ダイアログを出せないので、すでに信頼済みでなければ、プロジェクトのMCPサーバーは無効のままです。1回のプロセスだけ信頼するには、環境変数 KIMI_CODE_TRUST_WORKSPACE=1 を使います。永続的な記録は書かれません。

僕らの見立てです。既定が「信頼する」で、確認なしにEnterを押すと通るなら、他人のリポジトリを開く場面では、ダイアログの内容を実際に読む習慣が要ります。信頼の対象が、MCP以外の何にまで及ぶかの一覧は、読んだ範囲では見つかっていません。

人がいない場所で使う（-p）

kimi -p "指示" は、TUIを開かずに1回の指示を実行して終わります。出力は --output-format text（既定）か stream-json です。

• 公式のコマンド表は、--prompt に --yolo、--auto、--plan を組み合わせることはできない、と書いています。人の承認は求められず、通常のツール呼び出しは「auto」の方針で動き、静的な拒否ルール（deny）は適用される、とあります。
• 一方、「Config overrides」ページの例には、kimi --yolo -p "Batch rename the following files..." があります。同じ公式の中で、この2つが食い違っています。どちらが現行かは、読めた範囲では分かりません。notes に書きました。
• 拒否したいものは、config.toml の deny ルールに書いておくのが、読んだ範囲で確かな道です。

残るデータ：消せるものと、気をつけること

公式の「Data locations」によると、~/.kimi-code/（または KIMI_CODE_HOME）の下には、次のものが残ります。

消し方は表になっています。全部消すなら、データのルートを削除します。セッションだけなら sessions/ と session_index.jsonl、履歴だけなら user-history/、ログインだけなら /logout か credentials/<名前>.json の削除です。MCPのログインは /logout では消えず、credentials/mcp/ を消す、と書かれています。

共有するとき。 kimi export（または /export-debug-zip）は、セッションをZIPにまとめ、診断ログも含めます。公式は、コード、コマンドの出力、ファイルのパスが入りうるので、共有の前に中身を見るよう書いています。/feedback の添付は、「なし」「ログのみ」「ログとコードベース」から選べ、コードベースを付ける場合、.env や設定、秘密鍵などは自動で除かれる、とあります。「診断にだけ使い、共有しない」とも書かれています。

テレメトリ。 telemetry の既定は true（匿名）です。公式の設定ページは、何を集めるかを説明していません。止めるには、telemetry = false か KIMI_DISABLE_TELEMETRY=1 です。会員のデータの扱いは、01の記事に書いたとおり、アプリの規約とプライバシーポリシーが別にあり、Kimi Code CLIが送る内容がそのどれに入るかは、読んだ範囲では確認できていません。

つまずいたときの手がかり（公式のエラー表）

エラー表は、枠の不足（429）と権限の不足（403）は、再試行しても直らない、と書いています。ログイン時に「No models available for the selected platform」と出る場合、FAQは、鍵が違う、期限切れ、ネットワークの問題、そしてベースURLと鍵が同じ製品のものかを疑うよう書いています。

追加の使用量（Extra Usage）。 購読中の会員だけが有効にでき、枠を使い切った後に引かれます。月の上限は設定で決めます。上限を有効にしなければ上限なし、と書かれています（既定の設定値は読めていません）。チャージは1回25元以上など、人民元建てで、返金は基本的にない、と書かれています。具体的な額と条件は、公式のページで確かめてください（このページには日付が付いていません）。

前のガイドとの違いと、他のツールから移るとき

• 02では、承認のモードと設定を短く触れました。ここでは、各モードで何が止まるか、更新履歴で変わった点、ルールの書き方まで下げて書きました。
• 02に書いたKimi Codeのモデル（k3、k3-256k、kimi-for-coding、kimi-for-coding-highspeed）に加えて、2026年10月24日に読んだ「Model Configuration」には k3.1-pro と k3.1-pro-highspeed が載っていました（kimi-for-coding は「K2.8 Preview」と表示）。モデルとプランの対応は変わるので、/model で出る一覧と公式のページを見てください。
• 旧版の kimi-cli からは、kimi migrate で設定、MCPの設定、入力履歴、選んだセッションを移せます。OAuthの認証情報は移らず、/login が要ります。旧版の ~/.kimi/ は変更も削除もされない、と書かれています。
• Claude CodeやCodexを使ってきた人向けに、内蔵のスキルコマンド /import-from-cc-codex が、指示、スキル、MCPの設定の取り込みを担う、と書かれています（動きは読めていません）。

気をつけること

• この記事は、実際に使って確かめた記録ではありません。運営者はKimiを入れていますが、使い心地はこの記事には書いていません。公式ページは要約として取得したので、細かい条件は原文で確かめてください。
• 名前が新旧混ざる。 画面は「Always Ask」「Ask When Needed」「Never Ask」、設定値と旗は manual、yolo、auto です。検索で出る古い記事は旧名のことがあります。
• 「Ask When Needed」は、全部の危険を止めるわけではない。 静的に解析できないbashは、確認の対象外です（2.0.1）。
• 「Never Ask」は、承認の仕組み全体が止まる。 機密ファイルの確認、危険なコマンドの確認、計画の承認、質問のすべてが無い、と公式の記載から読めます。使うなら、使い捨ての環境、コンテナ、gitで戻せる場所だけにする、というのは僕らの見立てです。
• /undo はファイルを戻さない。
• 鍵は平文になりうる。 api_key を直接書くと、config.toml に平文で入ります。公式はこの形を例に載せています。gitに入れないこと。環境変数で渡すなら api_key_env。
• 自動更新が既定でオン。 [upgrade].auto_install は true です。
• kimi web を外に開かない。 kimi web は既定で 127.0.0.1 のポート58627に結び（使用中なら+1を試す、とあります）、--host（値なし）は 0.0.0.0 を意味します。公式は、--dangerous-bypass-auth を付けると、ポートに届く誰もが、セッション、ファイルシステム、シェルに入れる、と警告しています。外に出す場合は KIMI_CODE_PASSWORD が勧められています。
• フックは安全の最後の砦にならない。 公式は、フックは失敗時に許可する（fail-open）ので、唯一の防壁にしないよう書いています。
• 読めていない所。 日本からのログイン方法の細部（地域の選択）、プラン価格、AGENTS.md の読み込み規則、パターンの照合規則、信頼の対象の全体、CLIのテレメトリの中身は、読んだ範囲では確認できていません。
• 法律・契約の判断は含みません。社内のコードを入れる前に、会社の規則や規約を確かめてください。

出典

• Kimi Code Docs Overview（Kimi Code Docs、Moonshot AI、日付の表示なし、確認日2026-10-24）
• Kimi Code CLI Getting started（Moonshot AI、日付の表示なし、確認日2026-10-24）
• Kimi Code CLI Interaction and input（Moonshot AI、日付の表示なし、確認日2026-10-24）
• Kimi Code CLI Sessions and context（Moonshot AI、日付の表示なし、確認日2026-10-24）
• Kimi Code CLI Common use cases（Moonshot AI、日付の表示なし、確認日2026-10-24）
• Kimi Code CLI Migrating from kimi-cli（Moonshot AI、日付の表示なし、確認日2026-10-24）
• Kimi Code CLI Configuration files（Moonshot AI、日付の表示なし、確認日2026-10-24）
• Kimi Code CLI Providers and models（Moonshot AI、日付の表示なし、確認日2026-10-24）
• Kimi Code CLI Config overrides（Moonshot AI、日付の表示なし、確認日2026-10-24）
• Kimi Code CLI Environment variables（Moonshot AI、日付の表示なし、確認日2026-10-24）
• Kimi Code CLI Data locations（Moonshot AI、日付の表示なし、確認日2026-10-24）
• Kimi Code CLI Model Context Protocol（Moonshot AI、日付の表示なし、確認日2026-10-24）
• Kimi Code CLI Hooks（Moonshot AI、日付の表示なし、確認日2026-10-24）
• kimi Command（Moonshot AI、日付の表示なし、確認日2026-10-24）
• Slash Commands（Moonshot AI、日付の表示なし、確認日2026-10-24）
• Built-in Tools（Moonshot AI、日付の表示なし、確認日2026-10-24）
• Keyboard Shortcuts（Moonshot AI、日付の表示なし、確認日2026-10-24）
• Kimi Code CLI Changelog（Moonshot AI、最新は2.3.0の2026-10-21、確認日2026-10-24）
• Kimi Code What's New（Moonshot AI、最新の項目は2026-10-21、確認日2026-10-24）
• Kimi Code Model Configuration（Moonshot AI、日付の表示なし、確認日2026-10-24）
• Kimi Code Membership Benefits（Moonshot AI、日付の表示なし、確認日2026-10-24）
• Kimi Code FAQ（Moonshot AI、日付の表示なし、確認日2026-10-24）
• Kimi Code Error Reference（Moonshot AI、日付の表示なし、確認日2026-10-24）
• Kimi Code Contact & Feedback（Moonshot AI、日付の表示なし、確認日2026-10-24）
• MoonshotAI/kimi-code README（GitHub、Moonshot AI、確認日2026-10-24）