clasp 3.4でリンク先GASが送られない — 更新前の確認

スプレッドシートやフォームに付けた複数のApps Scriptで、共通の関数を1つのフォルダに置き、各プロジェクトからシンボリックリンクで参照して clasp push している。この構成のまま clasp を3.4系へ上げると、リンクしたファイルは送信の対象から外れます。編集部の検証では、clasp status は警告も出さず、終了コード0のままそのファイルを「Untracked files」へ移しました。

clasp 3.4.0（2026年8月21日公開）と3.4.1（8月28日公開）は、OAuthのPKCE対応やパストラバーサルの修正など、セキュリティの修正を多く含みます。上げるべき更新ですが、共有フォルダや認証情報ファイルの置き方によっては動きが変わります。CHANGELOGとソースを読み、3.3.0と3.4.1を同じ検証用プロジェクトで動かした結果から、更新前に確かめる点を整理します。

clasp 3.4.0・3.4.1で変わったこと

clasp はGoogleが公開している Apps Script のコマンドラインツールです。npmの登録情報では3.4.0が8月21日、3.4.1が8月28日（UTC）に公開され、10月2日時点の latest は3.4.1です。CHANGELOGから運用に関わる変更を抜き出しました。

Node.jsは、READMEに「NodeJS version >= 22.0.0」とあります。この記述は3.3.0のREADMEにもあり、3.4で加わった条件ではありません（package.json の engines は >=20.0.0 のまま）。3.4.0では依存ライブラリの更新で、Node 22以降・25以降との互換性の問題も直されています。

3.3.0と3.4.1で「送るファイル」を比べた

clasp show-file-status（別名 status）は、push の対象を一覧にするコマンドです。.clasp.json に scriptId があれば、ログインせずローカルだけで動きます。編集部の検証環境（Linux、Node v22.22.0、npm 10.9.4）で、ダミーの scriptId を入れた次のプロジェクトを使いました。Googleのサーバーには接続していません。

shared/util.js, shared/lib/a.js     共通の関数（実ファイル）
proj/.clasp.json                    {"scriptId": "dummy-script-id-for-local-test"}
proj/appsscript.json, proj/main.js
proj/util.js -> ../shared/util.js   ファイルへのリンク
proj/lib     -> ../shared/lib       フォルダへのリンク

図で見てほしい点は3つあります。

• ファイルへのリンク（util.js）は3.4.1の既定で対象外。 status は警告を出しません。push では、ソースコード上「Security Warning: Skipping symbolic link … Symbolic links are not supported.」と警告して送らない作りです（push は未実行）
• --allow-symlinks を付けると、3.3.0より送るファイルが増えることがある。 3.3.0はフォルダのリンク先（lib/a.js）を対象にしませんでしたが、オプション付きの3.4.1は対象にしました
• srcDir が外やリンクを指す構成は通らない。 "srcDir": "../shared" は3.3.0では通りましたが、3.4.1は「Security Error: srcDir ”../shared” escapes project root.」で終了コード1でした。オプションを付けても同じで、"rootDir": "../shared" と書いても同じエラーです。srcDir 自体をリンクにした場合は、オプションを付けるとエラーは消えたものの、対象は0件でした

ソースコードは .clasp.json の "allowSymlinks": true も同じ設定として読み込み、検証でも util.js が対象に戻りました。ただしREADMEに記載はなく、編集部は頼らない前提で扱います。

認証情報ファイルもリンクを拒む

~/.clasprc.json には clasp のOAuthトークンが保存されます。ダミーのトークンを入れたファイルへのリンクを置き、clasp logout で書き込みを起こして比べました。

• 3.4.1：「Security Error: Credential file is a symlink.」で終了コード1。ファイルは変わらない
• 3.4.1に --allow-symlinks：リンク先に書き込み、権限は600（所有者だけが読み書きできる）に変わった
• 3.3.0：リンク先に書き込み、権限は644のまま

ソースコードでは、--allow-symlinks はプロジェクトのファイルと認証情報ファイルの両方に効きます。共有フォルダのために付けると、認証情報の保護も同時に緩みます。

更新前に確かめる手順（編集部の提案）

1. リンクと外を指す設定を洗い出す。 各プロジェクトで find . -type l を実行し、.clasp.json の srcDir・rootDir に .. がないかを見ます。~/.clasprc.json がリンクかどうかも ls -l で確かめます
2. 上げる前後で対象の一覧を比べる。 status は警告を出さないため、差分で見ます

npx clasp status --json > before.json   # 3.3.0のまま
npm install --save-dev @google/clasp@3.4.1
npx clasp --version                      # 3.4.1 を確認
npx clasp status --json > after.json
diff before.json after.json

3. 共有コードは実ファイルで渡す。 ビルドの段階でプロジェクト内へコピーするか、バンドラーで1つにまとめます。--allow-symlinks を使うなら対象のコマンドに限り、増えたファイルを一覧で確かめてからにします
4. 認証情報ファイルは実ファイルに戻し、権限が600かを確かめる
5. 版をプロジェクトに固定する。 devDependencies に入れて npx clasp で呼び、人による版のずれをなくします

古いApps Scriptの引き継ぎや構成の整理は、前任者のGASを立て直す記事でも扱いました。

AIエージェントからclasp mcpを使う前に

clasp には、Claude CodeなどのコーディングエージェントからMCPサーバーとして使う clasp mcp があります（MCPの仕組みはMCP完全ガイド）。READMEは「EXPERIMENTAL」としたうえで、STDIOのローカルツールとして設定すること、CLIと同じ認証情報を使うため先に clasp login が要ること、プロジェクトのフォルダはツールの呼び出しごとに指定し、認証情報の切り替えには再起動が要ることを説明しています。

編集部の環境で3.4.1の clasp mcp を起動し、初期化とツール一覧の取得を行いました。ツールは push_files・pull_files・create_project・clone_project・list_projects の5つです。push_files に projectDir として /etc を渡すと、「Security Error: projectDir must be within the user home directory or current working directory.」で拒否されました。ログインしていない状態で、Googleに届く呼び出しはしていません。

つまり許可されるのは「ホームディレクトリか、起動したフォルダの下」で、対象のプロジェクトだけに絞る仕組みではありません。また、ソースコード上の push_files は、CLIの clasp push がマニフェスト（appsscript.json）の上書き前に出す確認を通らずに送信します。

権限を分ける設定（編集部の提案）

• 自社のOAuthクライアントを使う。 READMEは既定のクライアントより自社のプロジェクトを勧めています。Google Cloudで種類「Desktop Application」のOAuthクライアントを作り、--creds で渡します。サードパーティアプリの承認を制限している組織向けに、clasp のクライアントIDを許可リストに入れる方法と、社内専用のプロジェクトを使う方法も載っています
• エージェント用の認証情報に名前を付け、版を固定する。 グローバルの --user で人の default と分けます。READMEの例の npx -y @google/clasp mcp は起動のたびに最新版を取るため、版まで書きます

clasp login --user agent --creds client_secret.json
claude mcp add clasp -- npx -y @google/clasp@3.4.1 --user agent mcp
clasp show-authorized-user --user agent --json   # clientType が user-provided か

clasp --user agent mcp の形で起動できることは確かめました（ログイン後の動作は未検証）。ダミーのトークンで clasp logout --user agent を試すと、agent だけが消えて default は残りました。

• マニフェストの変更は人が見る。 スコープは appsscript.json に書かれます。エージェントが送る前に git diff で差分を確かめる運用にします。誰の権限で動かし、どこで人が承認するかは、ClaudeのGmail・Drive連携の承認設定と同じ論点です

落とし穴

• status に警告が出ないので見落とす。 リンクしたファイルは「Untracked files」へ移るだけです
• --allow-symlinks を常に付ける。 フォルダのリンク先まで送られ、認証情報ファイルの保護も緩みます
• MCPの許可範囲をプロジェクト単位と思い込む。 検証で確かめたのは、ホームディレクトリの外を拒むことまでです

2026年10月2日に、google/claspのCHANGELOG・README・package.json（npmの3.4.1の記録と同じcommit e9441e5。raw.githubusercontent.com経由）、v3.3.0のREADME、v3.4.1タグのソースコード（src/core/clasp.ts・src/core/files.ts・src/auth/file_credential_store.ts・src/auth/auth_code_flow.ts・src/mcp/server.ts・src/commands/program.ts・src/commands/pull.ts）、npmの登録情報を直接開いて照合しました。ファイル一覧・認証情報ファイル・MCPの検証は、編集部の検証環境（Linux、Node v22.22.0、npm 10.9.4）で clasp 3.3.0 と 3.4.1 を使い、ダミーの scriptId とトークンで1回ずつ行ったものです。Googleアカウントでのログイン、実際の push・pull、MCPのツールからApps Scriptへの操作、Windows・macOSでの挙動は確認していません。

Apps Scriptの開発環境の整理や、AIエージェントに持たせる権限の設計は、IT・Google Workspaceのご相談からお問い合わせください。

Sources

• google/clasp — CHANGELOG.md
• google/clasp — README.md
• google/clasp — README.md (v3.3.0)
• google/clasp — package.json
• google/clasp — src/core/clasp.ts (v3.4.1)
• google/clasp — src/core/files.ts (v3.4.1)
• google/clasp — src/auth/file_credential_store.ts (v3.4.1)
• google/clasp — src/auth/auth_code_flow.ts (v3.4.1)
• google/clasp — src/mcp/server.ts (v3.4.1)
• google/clasp — src/commands/program.ts (v3.4.1)
• google/clasp — src/commands/pull.ts (v3.4.1)
• @google/clasp — npm registry