exe-dev

exe.dev

exe.dev は、永続ディスク、即時利用可能な HTTPS、組み込み認証を備えた Linux VM を提供します。

ドキュメント

• ドキュメントのインデックス：https://exe.dev/docs.md
• すべてのドキュメントを1ページにまとめたもの（大容量！）：https://exe.dev/docs/all.md
• HTTPS API リファレンス：https://exe.dev/docs/https-api.md
• HTTPS API の紹介（ブログ）：https://blog.exe.dev/apis-for-the-restless

3つのインターフェース

exe.dev では、VM 管理のために同等の3つのインターフェースとして、SSH、SSH API（プログラムから利用する SSH）、HTTPS APIを公式にドキュメント化しています。いずれも同じコマンド構文を使用します。HTTPS API は「SSH API を POST ボディに詰め込んだもの」です。公式に推奨されているものはありません。状況に応じて選んでください。

インターフェース	用途
SSH	対話的なロビー操作。使い慣れた Unix 風の操作環境
SSH API	SSH エージェントをすでに読み込んでいる場合のスクリプト
HTTPS API	スコープ付き／有効期間限定トークン、アウトバウンドのポート22がブロックされている環境、オートメーションのセキュリティ強化

接続のレート制限

exe.dev のロビーと VM への直接 SSH（*.exe.xyz）のどちらも、送信元 IP ごとの接続レートが上限（正確な閾値は未公開）を超えると、インバウンド TCP SYN を黙って破棄します。2026-04-21 の確認はロビーのみが対象で、連続して実行した ssh exe.dev が5回中5回タイムアウトしました。2026-04-23 の再テストでは、確認範囲が拡大しました。VM の起動中に新規の ssh <vm>.exe.xyz を連続して実行したところ、VM エンドポイントでも同様に数分間ポート22がブロックされました。両エンドポイントで、同じ SYN 破棄対策が適用されています。

制限にかからないようにするには：

• Host exe.dev *.exe.xyz に対して SSH 多重化を有効にしてください（下記の「SSH config」を参照）。1つの永続接続で多くのコマンドを実行でき、閾値を下回る状態を保てます。対話的な利用とスクリプトでの利用のどちらにも重要な設定です。
• 多くのロビーコマンドを実行する必要があるスクリプトやエージェントでは、HTTPS API を使用してください。そのレート制限は、IP ごとのサイレントなブロックではなく、SSH キーごとに適用されます（ドキュメントに記載）。
• VM で Tailscale が起動したら、その後の VM アクセスには Tailscale SSH を優先してください（下記の「開発用 VM のセットアップ」を参照）。Tailnet のトラフィックは exe.dev のエッジではなく WireGuard を使用するため、レート制限を完全に回避できます。

VM への直接アクセス（SSH のみ）

ssh <vm>.exe.xyz              # shell
scp file.txt <vm>.exe.xyz:~/  # transfer file

すべての VM に、自動 TLS が設定された https://<vm>.exe.xyz/ が割り当てられます。

HTTPS API とスコープ付きトークン

HTTPS API の特徴は、スコープ付き権限を持つ SSH 署名のベアラートークンです。SSH キー全体を渡さずに、エージェント、スクリプト、CI ジョブに限定的な権限を与える場合に便利です。

トークンの形式：exe0.<base64url-payload>.<base64url-signature>。ペイロードは署名付き JSON で、次の4つのフィールドがあります。

フィールド	用途
cmds	明示的なコマンド許可リスト。親コマンドを許可してもサブコマンドは許可されません（ssh-key ≠ ssh-key list）
exp	Unix の有効期限タイムスタンプ。デフォルトでは無期限ですが、ドキュメントでは「常に exp を設定することを強く推奨」しています
nbf	有効開始時刻のタイムスタンプ（スケジュール済みトークン用）
ctx	X-ExeDev-Token-Ctx 経由で VM に渡される任意の署名付き JSON。アプリケーションレベルの認可データ

レート制限は SSH キーごとに適用されます。独立したワークロードには別々のキーを使用してください。リプレイ保護はないため、トークンの有効期間は短くしてください。最大8KBです。

トークンの発行

PERMS='{"cmds":["ls","new","rm","whoami"],"exp":1800000000}'
PAYLOAD=$(printf '%s' "$PERMS" | base64 | tr -d '\n=' | tr '+/' '-_')
SIG=$(printf '%s' "$PERMS" | ssh-keygen -Y sign -f ~/.ssh/exe_dev.pub -n [email protected] 2>/dev/null | sed '1d;$d' | tr -d '\n' | tr '+/' '-_' | tr -d '=')
TOKEN="exe0.$PAYLOAD.$SIG"

ssh-keygen -Y sign は1Password の SSH エージェントで動作します。公開鍵ファイルを渡すと、エージェントが署名を処理します。

トークンの使用

curl -s -X POST https://exe.dev/exec -H "Authorization: Bearer $TOKEN" -d "ls"
curl -s -X POST https://exe.dev/exec -H "Authorization: Bearer $TOKEN" -d "new --name myvm --image ubuntu:24.04"
curl -s -X POST https://exe.dev/exec -H "Authorization: Bearer $TOKEN" -d "rm myvm"

レスポンスは常に JSON です。

VM のデフォルト設定

• イメージ: デフォルトは boldsoftware/exeuntu です。ssh exe.dev new（--image なし）で exeuntu VM が作成されます。素の Ubuntu を使用する場合は、--image=ubuntu:24.04 を指定します。exeuntu は Bold のオーバーレイを適用した Ubuntu 24.04 です（Shelley/Pi エージェントスタックは ~/.config/shelley/ と ~/.pi/ にあり、~/.zed_server/ は事前にステージング済みです。Python ビルド依存関係を含む apt パッケージを多数備えており、素の Ubuntu で uv tool install snowflake-cli が失敗した問題にも対応しています）。
• デフォルトユーザー: イメージによって異なります。
  • exeuntu: exedev（uid 1000、sudo グループと docker グループに所属し、NOPASSWD sudo が有効）。$HOME=/home/exedev。一般的な非 root 開発環境のパターンです。
  • ubuntu:24.04: sudo がインストールされていない root。非 root ユーザーを作成するには、次を実行します。ssh <vm>.exe.xyz "apt-get update -qq && apt-get install -y -qq sudo && useradd -m -s /bin/bash myuser && echo 'myuser ALL=(ALL) NOPASSWD:ALL' > /etc/sudoers.d/myuser"。
• exeuntu 上の既存の ~/.claude/CLAUDE.md と ~/.codex/AGENTS.md: ~/.config/shelley/AGENTS.md を指す絶対シンボリックリンクです。dotfiles の install.sh はこれを検出してバックアップ（*.pre-dotfiles.<timestamp>）してから、agents パッケージを stow します。Bold の元ファイル ~/.config/shelley/AGENTS.md は保持されます。

VM の命名規則

• 名前の末尾に -<digits> を付けることはできません（例：test-123 は拒否されますが、test-abc は使用できます）
• 名前のほかの部分にはハイフンを使用できます
• 名前がサブドメインになります：<name>.exe.xyz

SSH 設定

1Password のエージェントがほかの鍵を提示しないように、exe.dev の鍵を指定する必要があります。また、前述のレート制限によるブロックを避けるため、lobby ホストと VM の直接接続先ホストの両方で接続多重化を有効にする必要があります。

Host exe.dev *.exe.xyz
  IdentitiesOnly yes
  IdentityFile ~/.ssh/exe_dev.pub
  ControlMaster auto
  ControlPath ~/.ssh/sockets/%r@%h-%p
  ControlPersist 600

秘密鍵は 1Password の Employee vault にある「SSH Key - exe.dev」です。ディスク上には公開鍵のみが ~/.ssh/exe_dev.pub にあります。

install.sh の macOS ブランチでは、関連する次の設定ブロックが追加されます。

Host *.exe.xyz
  User exedev
  LocalForward 8765 localhost:8765

Match host *.ts.net exec "$HOME/.local/bin/ssh-tailnet-tagged %h tag:dev"
  User exedev
  IdentitiesOnly yes
  IdentityFile ~/.ssh/exe_dev.pub
  StrictHostKeyChecking no
  UserKnownHostsFile /dev/null
  LogLevel ERROR

Host *.ts.net
  ForwardAgent yes

*.exe.xyz ブロックは常に適用されます。これは lobby 経由の接続です。Match host *.ts.net exec ブロックは動的に適用されます。ここでは ssh-tailnet-tagged（install.sh が ~/.local/bin に書き込む小さなヘルパー）が tailscale status --json を照会し、正規化されたホスト名が tag:dev を持つピアの場合にのみ 0 で終了します。これにより、新しくブートストラップされた exe.dev VM が tailnet に参加すると、すぐに ssh <new-vm> で接続できます。VM ごとの ssh_config エントリも、ほかの各マシンで install.sh を再実行する必要もありません。Mac やその他の tailnet ピア（tag:dev なし）は、ForwardAgent yes のみを指定した通常の Host *.ts.net ブロックにフォールスルーします。そのため、*.ts.net に一律で User exedev を設定するのは誤りでした（Mac へのログイン時にも exedev として接続しようとします）。

WireGuard がネットワーク層でピアをすでに認証するため、一致したホストではホスト鍵の確認が無効になっています。tailnet 上では通常の SSH ホスト鍵を追加しても意味がなく、VM を再構築するたびにローテーションされるためです。

LocalForward 8765 が適用されるのは *.exe.xyz 形式のみ です。Tailscale 名は意図的に対象外にしており、通常の ssh <vm> 接続でポート 8765 の競合が起きないようにしています。Zed のリモートサーバー用 SSH は永続的な接続を開いたままにします。Tailscale のパターンにも LocalForward を設定すると、その後のターミナルからの ssh <vm> は毎回 bind: Address already in use を記録し、トンネルも機能しなくなります。

MCP OAuth フローでは、ssh <vm>.exe.xyz を使用してください。これによりトンネルが利用できます。普段の作業では ssh <vm>（Tailscale）を使えば、ポートを占有しません。

スクリプトやエージェントでの作業

• ロビーの自動化には、HTTPS API のほうがスムーズなことがよくあります — トークンの cmds を制限すれば、エージェントに必要な権限だけを付与できます。
• SSH 多重化は ~/.ssh/config に設定されています（install.sh によって追加されます）。そのため、ssh <vm>.exe.xyz を繰り返し実行しても、1 つの TCP 接続が再利用されます。呼び出しごとの ControlPath フラグで上書きしないでください。ソケットプールが分断され、レート制限の緩和効果が損なわれます。
• 初回接続時に、新しいホストキーを非対話的に受け入れます：-o StrictHostKeyChecking=accept-new。
• 接続タイムアウト： VM への SSH には -o ConnectTimeout=30 を使用してください。新しい VM が接続可能になるまで数秒かかります。
• Tailscale が起動したら、以降の作業では Tailscale SSH に切り替えてください。 下記の「SSH エンドポイント」を参照してください。

SSH エンドポイント — 使い分け

ドットファイルのインストール後、起動中の VM には 2 つの SSH エンドポイントから接続できます。

エンドポイント	使用する場面
ssh <vm>.exe.xyz（exe.dev）	ブートストラップ時のみ。 Tailscale の起動前（curl によるインストールと install.sh の実行段階）に必要です。VM 上の Tailscale に問題がある場合や、テイルネットに接続していない Mac からのフォールバックとしても便利です。
ssh <vm> / ssh <vm>.dojo-sun.ts.net	ブートストラップ後のすべての作業でのデフォルト。 1Password の SSH エージェントを転送するため（プライベートリポジトリのクローン、プッシュ、署名に対応し、VM にトークンを置く必要がありません）、exe.dev の IP ごとのレート制限を回避でき、VM 再構築時に SSH ホストキーが変更されません（Tailscale は OpenSSH のホストキーではなく WireGuard で認証します）。また、クロスプラットフォームの習慣として、Apple Containers や Sprites と同じパターンを使えます。

目安： VM で Tailscale が起動している場合は、まず ssh <vm> を使ってください。ssh <vm>.exe.xyz はブートストラップ期間と緊急時に限って使用します。

ssh <vm> が User exedev を使う仕組み： install.sh は ~/.ssh/config に Match host *.ts.net exec "..." ブロックを出力し、接続時に ~/.local/bin/ssh-tailnet-tagged を実行します。このヘルパーは tailscale status --json を照会し、ピアが tag:dev を持つ場合にのみ 0 で終了します。そのため、新しい exe.dev VM はテイルネットに参加した時点ですぐに動作します。VM ごとの設定は不要で、VM を追加するたびに他のマシンで install.sh を再実行する必要もありません。tag:dev を持たない Mac やその他のテイルネットピアは、通常の Host *.ts.net ブロック（ForwardAgent yes のみ）にフォールスルーします。

VM 間アクセス

exe.dev VM には /dev/net/tun と CAP_NET_ADMIN があるため、install.sh は カーネルモード で tailscaled を実行します。実際の tailscale0 インターフェース、100.0.0.0/8 のカーネルルート、システムリゾルバーに組み込まれた MagicDNS を利用できます。Mac からの場合と同じように、ssh <vm> で VM 間の接続ができます。

# from inside any exe.dev VM (use the username that matches the destination's image)
ssh exedev@gitlake 'cd ~/dotfiles && git pull && ./install.sh'   # exeuntu
ssh root@gitlake 'cd ~/dotfiles && git pull && ./install.sh'     # ubuntu:24.04

これには、Tailscale ACL でネットワークグラントと SSH ルールの両方について、tag:dev → tag:dev を許可する必要があります（管理コンソール）。SSH ルールの users リストには、ログイン先となるユーザーを含める必要があります。通常、exeuntu では exedev、ubuntu:24.04 では root です。

ユーザー空間モードへのフォールバック。 /dev/net/tun が利用できない場合（Apple Containers の一部の構成、Sprite など）、install.sh は tailscaled --tun=userspace-networking にフォールバックします。このモードでは通常の ssh <vm> は機能しません（tailnet IP へのカーネルルートがないため）。代わりに tailscale ssh <vm> を使ってください。これは tailscaled のユーザー空間 TCP スタックを経由してプロキシ接続します。

名前変更後の Tailnet ID — 再起動では解決しません

VM の tailnet 名は、tailscale up の実行時に記録された --hostname であり、以降 OS から再読み込みされることはありません。そのため、OS のホスト名が変更されても（たとえば、再作成した VM が <name>-next として参加し、その後 <name> に名前変更されても）、ノードは 古い 名前のままになり、ピアは正規名で接続できません。「tailnet にはいるが通信できない」状態に見えます。これを解決できない方法が 2 つあります（2026-08-02 にカナリアで測定済み）：hostnamectl set-hostname と systemctl restart tailscaled です。再起動しても、保存済みの名前が再アナウンスされるだけです。解決するには 再登録 が必要です。sudo tailscale logout を実行してから再参加してください（join-tailnet.sh <vm> は、要求されたホスト名に対して冪等であり、まずその名前を保持している古いノードを削除します）。再登録すると新しいノードが作成されるため、tailnet IP も変わります。古い IP に固定されているものはすべて更新する必要があります。tailnet への接続性を解決する方法として「tailscaled を再起動する」と案内してはいけません。再登録してください。

Dev VM のセットアップ

デフォルトのセットアップスクリプト（exe-setup.sh）は ssh exe.dev defaults write で登録されており、新しい VM ごとに Tailscale と dotfiles が自動的に設定されます。リポジトリを使える状態にするコマンドは 2 つです。

1. VM を作成してリポジトリをクローンする（約4秒）

ssh exe.dev new --name=<vm> --tag=iv \
  --integration=github-<org>-<repo>
ssh -o ConnectTimeout=30 -o StrictHostKeyChecking=accept-new <vm>.exe.xyz \
  "git clone https://github-<org>-<repo>.int.exe.xyz/<org>/<repo>.git ~/<repo>"

• --tag=iv を指定すると、VM に IV スコープのインテグレーション（work GitHub MCP、MotherDuck）へのアクセスが許可されます
• --integration=github-<org>-<repo> を指定すると、リポジトリごとのクローン／プッシュ用インテグレーションが追加されます
• 個人用 VM の場合は、作成後に github-mcp-home も追加してください：ssh exe.dev integrations attach github-mcp-home vm:<vm>

GitHub インテグレーションの名前は github-<org>-<repo> です（例：github-kylelundstedt-gitlake）。新しいリポジトリを登録するには：

ssh exe.dev integrations add github --name github-<org>-<repo> --repository <org>/<repo>

インテグレーションのスコープ設定

インテグレーションのスコープは、VM 間での認証情報の露出を最小限に抑えるよう設定されています。

Integration	Scope	Grants
tailscale-api	auto:all (個人用)	Tailscale API — セットアップスクリプトの起動時に必要
github-mcp-work	tag:iv	Work GitHub API（issue、PR、コード検索）
motherduck-mcp	tag:iv	MotherDuck SQL クエリ
github-mcp-home	vm: VM ごと	個人用 GitHub API — 自分の VM のみ
github-<org>-<repo>	vm: VM ごと	単一リポジトリ用 Git のクローン／プッシュ
reflection	auto:all	VM メタデータ（無害）

チームメンバーが SSO 経由で参加した場合、個人用インテグレーションは表示されません。チームインテグレーション（--team フラグ）は tag: のアタッチのみをサポートします。アクセス範囲を設定するには、クライアント固有のタグ（例：iv、usaa）を使用してください。

セットアップスクリプト

デフォルトのセットアップスクリプト（dotfiles リポジトリの exe-setup.sh）は初回起動時に実行され、次の処理を行います。

• 同じホスト名を持つ古い Tailscale ノードを削除します（-2 サフィックスの付加を防ぎます）
• tailscale-api HTTP プロキシ統合を介して、単回使用のエフェメラル認証キーを生成します
• tailscaled を起動して認証します（ssh exe.dev new の実行後、約 6 秒で tailscale status にピアが表示されます。短い名前での ssh <vm> は約 10～12 秒後に使用できます）
• Tailscale の起動後、install.sh をフォアグラウンドで実行します（約 60 秒）

exe-setup.sh は、完全なインストールより先に Tailscale を起動するための専用スクリプトです。同じ認証キー／プロキシのロジックは install.sh の setup_tailscale にもあります（install.sh を単独で実行した場合のフォールバックとして使用されます）。ただし、exe-setup.sh 経由で実行すると、VM がテールネットに参加するまでの時間を約 3 分短縮できます。

デフォルトに設定するには（1 回限り。設定済みです。ファイル名を変更したり、場所を移動したりした場合は、再度実行してください）。

ssh exe.dev "defaults write dev.exe new.setup-script 'curl -fsSL https://raw.githubusercontent.com/kylelundstedt/dotfiles/master/exe-setup.sh | bash'"

exe.dev のフックシステムとの契約は 2 つあり、どちらも正しく設定する必要があります。

1. 登録先の URL が存在している必要があります。 raw.githubusercontent.com/.../master/exe-setup.sh が 200 を返す必要があります。
2. 登録先は install.sh ではなく exe-setup.sh である必要があります。 どちらも動作しますが、install.sh では apt と CLI ツールのインストール後に Tailscale が起動するため、Tailscale の起動まで約 30 秒かかります（ピアが表示されるまで実測で 34～36 秒）。exe-setup.sh は Tailscale を先に起動するため、ピアが表示されるまで約 6 秒です。登録先の違いは通知されません。VM のブートストラップ自体は行われますが、時間がかかります。

両方を同時に確認するには、次を実行します。

ssh exe.dev "defaults read dev.exe new.setup-script"   # should contain exe-setup.sh, not install.sh
./test-install.sh hook                                  # verifies URL returns 200

登録先にずれが生じた場合は、上記の defaults write コマンドで再設定してください。test-install.sh hook は URL を確認しますが、登録先のファイルまでは確認しません。ずれが生じた場合、ユーザーには「VM がテールネットに表示されるまで 6 秒ではなく 30 秒かかる」という症状が現れます。

2. コミット署名

コミット署名には、1Password SSH エージェントを転送する Tailscale SSH（ssh <vm>）を使用してください。ログイン時に .zshrc が転送されたエージェントを検出し、コミット署名を自動的に有効にします。

3. MCP サーバー

5 つの MCP サーバーのうち 3 つは、exe.dev の HTTP プロキシ統合を介して自動的に接続されます。新しい VM での設定は不要です。

サーバー	プロキシ統合	認証
motherduck	motherduck-mcp.int.exe.xyz	静的ベアラートークン（自動）
github-home	github-mcp-home.int.exe.xyz	静的ベアラートークン（自動）
github-work	github-mcp-work.int.exe.xyz	静的ベアラートークン（自動）
tigris	—	OAuth（ブラウザーでの操作が 1 回必要）
readwise	—	OAuth（ブラウザーでの操作が 1 回必要）

install.sh は 5 つすべてのサーバーを自動的に登録します。プロキシ経由の 3 つのサーバーはインストール直後に「接続済み」と表示されます。Tigris と Readwise は、OAuth フローが完了するまで「認証が必要」と表示されます。

Tigris／Readwise の OAuth フロー（VM ごとに 1 回限り）：

ssh <vm>.exe.xyz                # use the .exe.xyz form — carries LocalForward 8765
claude                          # inside the VM, start an interactive session
# /mcp → pick a server marked "Needs authentication" → Authenticate
# claude prints an http://localhost:8765/... URL — open it in the Mac browser

Tailscale 形式（ssh <vm>）では、意図的に LocalForward を使用していません。使用すると、Zed の永続的なリモートサーバー SSH が通常の接続のたびにポート 8765 を奪い合ってしまいます。ポート 8765 のバインドが競合するため、VM 間では一度に 1 つの OAuth フローのみ実行してください。トークンは VM ごとに ~/.claude/ にキャッシュされるため、この手順はサーバーごとに VM あたり 1 回だけ必要です。

4. Zed から接続する

Tailscale のホスト名を使用してください（~/.ssh/config の正規化ブロックにより、短い形式も使用できます）。ユーザーとホームパスはイメージによって異なります。

zed ssh://exedev@<vm>/home/exedev/<repo>   # exeuntu (default)
zed ssh://root@<vm>/root/<repo>            # ubuntu:24.04

オブジェクトストレージ連携（Tigris / S3）

exe.dev の「Object Storage」連携は s3 タイプの連携で、Tigris バケット（t3.storage.dev）をバックエンドとする S3 互換のパス形式プロキシを https://<integration>.int.exe.xyz で公開します。認証情報はエッジで注入されるため、VM はプレースホルダーの認証情報を送信し、プロキシが実際の Tigris キーで再署名します。そのため、VM に秘密情報が保存されることはありません。

エンドポイントのホスト名はバケット名ではなく、連携名です。 プロキシは https://<integration>.int.exe.xyz で稼働し、<integration> は連携の名前です。バケット名と同じとは限りません。推測せず、必ず確認してください。ssh exe.dev integrations list を実行すると、<name> s3 endpoint=… bucket=… が表示されます。たとえば、連携 bucket-gitlake-examples はバケット gitlake-examples を公開するため、ホスト名は bucket-gitlake-examples.int.exe.xyz ですが、パスには gitlake-examples を使います。VM ごとに ssh exe.dev integrations attach <name> vm:<vm> でアタッチしてください。

パス形式のみ対応しています。 プロキシは URL の パス（.../<bucket>/<key>）からバケットを読み取ります。仮想ホスト形式（バケット名をサブドメインにする形式）は失敗します。<bucket>.<name>.int.exe.xyz は *.int.exe.xyz の TLS 証明書と一致せず、ホスト名にバケットを指定してパスを / にすると 403 "account-level operations are not allowed" が返されます。すべてのクライアントでパス形式を使用する必要があります。

tigris CLI

TIGRIS_FORCE_PATH_STYLE を使ってパス形式を強制した場合にのみ動作します。この環境変数は 3.1.0 より後に追加されました（3.6.1 では存在し、3.1.0 では存在しないことを確認済みです）。古い tigrisdata/cli リリースや古いイメージには、この環境変数に対応していない CLI が含まれているため、tigris --version が最新であることを確認してください（install.sh は現在、tigrisdata/storage から取得します）。

export TIGRIS_STORAGE_ENDPOINT=https://<integration>.int.exe.xyz
export TIGRIS_FORCE_PATH_STYLE=1               # REQUIRED — the proxy is path-style
export TIGRIS_STORAGE_ACCESS_KEY_ID=x          # placeholders; edge injects the real cred
export TIGRIS_STORAGE_SECRET_ACCESS_KEY=x
tigris ls <bucket>
tigris cp ./file t3://<bucket>/key             # up/download/rm all work

tigris CLI 独自の S3 クライアントは CRC64NVME ストリーミングトレーラーを出力しないため、追加のフラグなしでアップロードできます。

aws CLI / SDK（boto3、aws-sdk-js、rclone）

同じエンドポイントを使い、パス形式のアドレス指定とプレースホルダー認証情報を設定します。

AWS_ACCESS_KEY_ID=x AWS_SECRET_ACCESS_KEY=x \
aws s3 ls s3://<bucket> --endpoint-url https://<integration>.int.exe.xyz

最近の aws-cli v2 はデフォルトで CRC64NVME チェックサムトレーラーを送信しますが、プロキシはアップロード時にこれを拒否し、SignatureDoesNotMatch を返します。無効にしてください（~/.aws/config でも設定できます）。

export AWS_REQUEST_CHECKSUM_CALCULATION=when_required
export AWS_RESPONSE_CHECKSUM_VALIDATION=when_required

boto3：Config(s3={"addressing_style": "path"})。rclone：force_path_style = true。

署名付き URL

プロキシは、署名済みの t3.storage.dev URL を返す署名付き URL ヘルパーを公開します。

curl -sX POST https://<integration>.int.exe.xyz/_/presign -d '{"key":"path/to/object"}'

注意事項

• アカウントレベルの操作（ListBuckets、パス /）は設計上禁止されています。連携の認証情報は単一のバケットに固定されています。
• 署名なしの通常の curl "https://<integration>.int.exe.xyz/<bucket>/?list-type=2" も動作します（エッジが認証情報を注入します）。到達性の確認に便利です。