セキュリティとプライバシー

このページにはあなたができることだけを書きます：トラフィックの行き先を知る、認証情報を正しい場所に置く、データがどこに残るかを知る、ローテーションできるようになる。tansr 内部の防御線（権限エンジン、保護パス、ハードなセキュリティレッドライン、監査チェーン）は各形態のガイドですでに展開されており、ここではあなたの操作に関係する場合にだけ参照します。バージョンの基準：tansr CLI 0.10.3、@tansr/sdk 0.19.0、@tansr/serve 0.15.1（いずれも 2026-10-10 公開）。

外向き通信：トラフィックはどこへ行き、どう絞るか

CLI は何に接続するか

宛先	いつ	無効化できるか
tansr プラットフォームゲートウェイ `api.tansr.com`	プラットフォームモードにログイン後：モデル呼び出し、設定バンドルの取得、ハートビート、使用量の報告、残高	`TANSR_ESCAPE_LOCAL=1` を設定して完全ローカルモードに入れば全体を停止
更新チェック：npm インストール形態は npm レジストリ `registry.npmjs.org` を、単一ファイル実行版（SEA）は公式配布サイト `bash.tansr.com` の署名付きポインタを照会する	あなたが明示的に `/update` または `tansr update` を実行したときだけ。起動時に自動チェックは行わない	`TANSR_UPDATE_CHANNEL=none` または `TANSR_NO_UPDATE_CHECK=1`。企業はセルフホストのマニフェスト `TANSR_UPDATE_MANIFEST_URL` を指定可能（指定があれば両形態ともそこにだけ接続する）
あなたが設定したモデルプロバイダー	完全ローカルモードでの `providers.*.baseUrl`	あなたが決める
あなたが設定した MCP サーバー / 自前の検索・メディアエンドポイント	セッション内のツール呼び出し	あなたが決める。プロジェクト層の MCP サーバーは明示的に信頼を付与する必要がある
モデルがツール経由でアクセスする任意の URL（WebFetch / Http）	セッション内	権限ルールの制約を受ける。`deny` ルールでツール全体を無効化できる

無人運転のデプロイ（tansr serve / headless で auto に権限を開放）の推奨ベースラインはネットワーク出口の許可リストです：モデル API などの必要な宛先だけを許可し、DNS と確立済み接続以外はデフォルトで拒否します。コンテナや最小権限の専用ユーザーと組み合わせ、ファイルシステムの書き込み面は作業ディレクトリに限定します。参考テンプレートはリポジトリ内の deploy/serve/ にあります。

すでに存在する、ユーザーに見える 2 つの防御線：同じ 1 つのコマンドで秘密ファイル（.env、キー、.aws/credentials）を参照しつつ外部送信の動作（curl / scp / git push …）を伴うものは常に拒否され、どのモードやルールでも覆せません。セッションが一度秘密ファイルを読むと、その後の外部送信の動作はすべて確認に変わります（セッション汚染）。tansr CLI 0.6.0 以降：すべての外向き通信（WebFetch / Http / hooks / 音声ダウンロード）を統一された出口経由に変更し、DNS 解決後にプライベートネットワーク、ループバック、リンクローカルアドレスを判定し、内部ネットワークやメタデータアドレスを指す取得は理由を示して拒否します。Http ツールと hooks が参照できる認証情報の環境変数は許可リスト http.allowedAuthEnvVars に収束し、リスト外ではリクエストを送信しません。

SDK とセッションサービスは何に接続するか

@tansr/sdk のトークン方式は、あなたが渡した baseUrl（プラットフォームゲートウェイ）と明示的に設定した MCP サーバーにだけ接続します。SDK はユーザーディレクトリをスキャンせず、自前の検索エンドポイントも持ちません。
@tansr/serve の上流チェーンは appid/appkey → POST /v1/app-tokens → GET /t1/config + POST /t1/heartbeat → POST /t1/exchange で、すべて apiBaseUrl を指します。ほかに、あなたが設定したターン終了時の webhook URL（アウトバウンドリクエストには認証情報のヘッダーを一切付けず、真正性は署名で確認）と、任意のコールド層オブジェクトストレージがあります。
モバイルアプリがコンソールでウェブページ取得（WebFetch）または HTTP リクエスト（Http）を有効にすると（@tansr/serve 0.12.0 以降、デフォルトは無効）、この 2 つのツールはセッションサービスが動くホストから直接ターゲット URL にアクセスし、同じ外向き通信の規則に従います。ホスト型 Http はホストの環境変数にある認証情報を参照できず、モデルもホストのプライベートネットワークへのアクセス上限を解除できません。外向きプロキシを設定している場合は、プロキシ側でも同様にプライベートネットワークの宛先を制限してください。詳しくはモバイルアプリ向けの公開ネットワークツールを参照してください。
モバイル SDK と @tansr/api-client はあなたのセッションサービスの baseUrl にだけ接続し、プラットフォームに直接接続せず、これらのツールのリクエストをデバイス上で代わりに送信することもありません。

統一呼び出し面 `/api`：ヘッダー、フェンス、旧プレフィックス

@tansr/serve 0.13.0 以降、options.v2 があるデプロイは同じポートのチェーン先頭に統一呼び出し面 /api を組み立てます（0.14.0 は manifest revision 7）。セキュリティに関係するのは次の数点だけです：

身元は Authorization からだけ来ます。 /api と /v2 は同じ authenticate フックで endUserId を裁定します。4 つのレスポンスヘッダー tansr-contract / tansr-manifest-revision / tansr-domain / tansr-schema-hash と、エラーエンベロープの traceId / requestId には endUserId、トークン、メッセージ内容を決して含めません。リクエストボディ内の身元フィールドはいかなるものも身元として扱われません。tansr serve --v2 の CLI 形態は同じ Bearer + x-tansr-end-user ヘッダーで分割ドメインを自己申告しますが、このヘッダーはあなたのゲートウェイが自前のログイン状態の後にだけ書き込むべきもので、端末に直接入力させてはいけません。
リクエストヘッダーはすべて明示的な交渉であり、認証要素ではありません。 tansr-session-family、tansr-closure-id、tansr-event-envelope、Idempotency-Key / If-Match / deadline（後ろの 3 つは 0.14.0 以降）が該当しないリクエストに現れた場合は一律 400 invalid_request で、黙って無視されることはありません。どのヘッダーも付けなければ、挙動はバイト単位で変わりません。
能力クロージャのフェンス：GET /api/sessions/:id/capabilities は各ドメインの既存の能力ソースを読み取り専用で連合し、操作の三状態表（enabled / disabled / unavailable）と tansr-closure-id を返します。これは新しい認可エンジンを作るものではなく、フェンス内の操作は引き続きドメインの handler がアプリの能力ビット、ユーザーの認可、セッション状態、承認に基づいて裁定します。書き込み操作は前回の tansr-closure-id を前提条件として付けられます。フェンスが変わっていれば 412 precondition_failed（rediscover。再発見してから再送するかを決め、古い値のまま強引に再送してはいけません）、フェンスを越えて disabled の操作を呼べば 403 capability_unavailable です。未知のセッション、他人のセッション、アーカイブホストにだけ存在するセッションはいずれも 404 not_found で、存在の有無を漏らしません。
/v1 はデフォルトで無効：ファサードがあるデプロイでは /v1/sessions*、/v1/status、/v1/approvals/:id/credential がデフォルトで 404 になります（SDK2 の明示的なホストがある場合は常に無効）。移行用のノブ tansr serve --legacy-v1 / TANSR_SERVE_LEGACY_V1=1 は 0.14.0 / CLI 0.10.1 以降は非推奨です（1.0.0 で削除。有効にすると warn イベント server.deprecated_option が出ます）。承認用の認証情報の送付は POST /api/approvals/:id/credential に移ります。ヘルスチェックは /healthz /readyz に替え、/v1 の Bearer で /v1/status を探るのはやめてください。
旧プレフィックス /v2、/v3/* の退役ウィンドウは設定できる（@tansr/serve 0.15.0 / CLI 0.10.2 以降、ファサードがあるときに有効）：TANSR_SERVE_LEGACY_PREFIX=readwrite|readonly|off（ファクトリオプション legacyPrefixes）——readwrite がデフォルトで（0.15.1 でも同じ）、旧プレフィックスの要求をすべて受け付けます。readonly では manifest が書き込みとして登録している操作が旧プレフィックスで 410 gone を返し（message は対応する /api の操作を指す）、読み取りとストリームはそのまま使えます。off では旧プレフィックスの要求がすべて 404 not_found になります。TANSR_SERVE_LEGACY_SUNSET（legacyPrefixSunset）で退役予定の時刻を指定すると、旧プレフィックスの応答に既存の Deprecation / Link ヘッダーに加えて Sunset ヘッダーが付きます。同じセッションで旧プレフィックスと /api を混ぜて使うとログに warn イベント api.legacy_prefix_mixed が出て、拒否された旧プレフィックスの要求には api.legacy_prefix_rejected が出ます——両方がゼロのまま続くことが、ウィンドウを狭めてよい根拠です。デフォルトがいつ変わるかは移行と退役のタイムラインを参照してください。
統一エラーエンベロープの message は字面を保証せず、detail.path にはリクエストされた /api のパスが書き戻され、/v2 / /v3 の内部プレフィックスとホストのパスは外に漏れません。各ヘッダーとコード表は統一 API のリクエストヘッダーとエラーエンベロープを参照してください。

システムツールとターミナルツールの分離（SDK 2.0 リモートプロファイル）

SDK 2.0 の「統一コアと薄いターミナル」は、ツールを実行場所で 2 種類に分け、どちらも相手の代わりに実行することはできません：

システムツールはセッションサービスのホストで実行：WebFetch / Http / WebSearch / メディアツールと MCP アダプターは serve プロセス内でホストの外向き通信の規則（プライベートネットワークの上限、認証情報の許可リスト、プロキシ側の同じ規則）に従って動きます。MCP アダプターはホストの既存の接続を再利用し、モデルのパラメータに基づいてプロセスを起動することはできず、モデルも外向き通信の上限を解除できません。
ターミナルツールはバインドされたデバイスでだけ実行：ファイル読み取り / ディレクトリ一覧 / 書き込み / 編集とバインドされたワークスペースのメモリ（fs.inspect / fs.read / fs.list などの制御されたプリミティブ）は、アプリが管理 API で明示的に execution.version = 'bound-device-v1' を設定し、boundDevice.tools で付与したときにだけ存在します。旧来のアプリ種別と旧来の tools ビットからターミナルの認可は導出されません。有効なツール = アプリの上限 ∩ ユーザーポリシー ∩ リクエストの絞り込み ∩ デバイスのプリミティブ。元の Read / List の権限とユーザーの承認は従来どおり有効で、設定ディレクトリがユーザーの代わりに認可することはできません。
メモリと添付ファイルはホストに戻りません：信頼済みホストの execution.memoryFor(scope) はバインドされたワークスペース内の相対ディレクトリだけを選び、serve の home / env / cwd を読みません。能力の欠如、拒否、切断、ソースの過大はいずれもそのターンだけを縮退させ、サーバー側のファイルを読む動作に切り替わることは決してありません。外部添付ファイルのソース trustedAttachmentSourceFor の URL は参照表のキーにすぎず、SDK / serve は自動で fetch せず、モデルやクライアントがアドレスをファイル権限やネットワーク権限に変えることも受け付けません。
耐久実行は先に記録してから実行：実行器は操作を先に永続的に占有してから実行し、結果を先に保存してから返します。切断後の再開では、結果が未知の操作をやり直しません（SDK 層では GateDecision.executionTarget / ToolContext.executionTarget に対応し、@tansr/sdk 0.18.0 以降。プロセス内 SDK では常に存在しません）。
信頼済みホストモジュールはデプロイ担当者のコードと同じ水準で信頼されます：tansr serve --v2 --host-module <absolute.cjs> --host-module-sha256 <sha256>（CLI 0.10.0 以降）はエントリファイルの生のバイト列のダイジェストだけを照合し、依存グラフに署名するものでも、コードサンドボックスでもありません。パスとダイジェストは常にデプロイパイプラインが与え、モデルや HTTP から与えられるものではありません。

認証情報：どこに置き、どこに置かないか

認証情報	誰を表すか	正しい場所	決して置かない場所
個人アクセストークン（PAT）	あなた本人	コンソールで生成後、`tansr init`（マスク入力）または CI の `TANSR_PAT` 環境変数にだけ渡す	シェル履歴（`--pat` で直接渡すと痕跡が残る）、スクリプトの平文、リポジトリ
このマシンの派生アプリキー	あなたのこのデバイス	`tansr init` が自動で OS キーチェーン（macOS Keychain / Linux secret-service / Windows DPAPI）に書き込む。使えない場合は 0600 のファイルにフォールバックし明示的に警告	あなたが触る必要はない。`tansr doctor` の認証情報ストレージのセクションで保存先を確認できる
モデルプロバイダーの API キー（完全ローカルモード）	あなたのプロバイダーアカウント	環境変数。設定ファイルには変数名だけを `auth.env` に書く	`settings.json`、エラーメッセージ、`/config` の出力（これらは値を決して含まない）
アプリキー appid / appkey	あなたのアプリ	あなたのサーバー側プロセスの環境変数（Node プロセスまたは `@tansr/serve`）	端末デバイス、ログ、エラーレスポンス、リポジトリ（`.env` は `.gitignore` に）
短期 `app_user` トークン	あなたのあるエンドユーザー	Electron メインプロセスのメモリ。`@tansr/serve` プロセスの内部	renderer プロセス、永続ストレージ。モバイル側は決して触れない
あなた自身のログイン token（モバイル）	あなたのユーザー	`authProvider` 経由でリクエストごとに提供し、SDK は永続化しない	SharedPreferences / DataStore / UserDefaults / ログ
セッションサービス `/v1` Bearer（`--token` / `TANSR_SERVE_TOKEN`）	運用者	環境変数	`/v2` / `/api` 面とは相互に通用しない。エンドユーザーに再利用しない。`--v2` デプロイでは `/v1` はデフォルトで無効
`--host-module-sha256` のダイジェスト	あなたのデプロイパイプライン	ビルド成果物のそばで `.cjs` と一緒に生成し、一緒に配布する	実行時に計算せず、モデルや HTTP から与えない
webhook `secret`	あなたのプッシュバックエンド	セッションサービスと受信側それぞれの環境変数	ログ。エンジンは決して出力しない

繰り返し言う価値のあるレッドラインが 3 つ：appkey は決してあなたのサーバーの外に出さない。app_user トークンは決してセッションサービスの外に出さない。セッション id は認証要素ではない。

CLI にはもう 1 層、あなたのためのマスキング規律があります：レポート、ログ、エクスポートしたトランスクリプトの中のキーは一律 sk-...末尾 4 桁 の形にマスキングされます。tansr sessions export の成果物はそのままチケットに添付できます。

プロジェクト層 hooks の信頼ゲート：デフォルトはゼロ実行

tansr CLI 0.7.0 以降で提供。 リポジトリ内の .tansr/settings.json / .tansr/settings.local.json は command / http の 2 種類の hooks を宣言できます。これは「リポジトリをクローンしただけで実行されうるコード」なので、CLI はプロジェクト層 hooks をワークスペース信頼ゲートの後ろに置き、デフォルトでは実行しません。

信頼記録はユーザー層 ~/.tansr/trust.json にあり、別の許可ファイルは作りません。ワークスペースが信頼済みと記録されている → プロジェクト層 hooks は通常どおり実行。記録なし、または不信頼と記録 → プロジェクト層の command / http hooks はゼロ実行（hook.* イベントもゼロ）で、stderr に 1 行の説明を残します。ユーザー層・管理層の hooks は影響を受けません。
TUI：記録のないディレクトリを初めて開いたとき、ユーザー層・管理層の SessionStart hooks は従来どおり初回画面の前に発火し、プロジェクト層の SessionStart は信頼ダイアログで「信頼する」を選んだ後にちょうど 1 回だけ発火します（拒否 / Esc では発火せず、引き締めモードに入ります）。
無人運転の 4 つのエントリ（headless -p、tansr serve、tansr acp、tansr mcp serve）には対話面がなく、TUI が永続化した記録だけを認めます。TUI で信頼したリポジトリは、CI やエディタから接続したときにプロジェクト hooks が自動で有効になります。記録がなく、今回だけ本当に必要なら、--trust-project-hooks（4 エントリ共通のフラグ名）を付けるか TANSR_TRUST_PROJECT_HOOKS=1 を設定します（他の値は無効）。これは記録がないときだけ、今回の実行だけに効き、trust.json には書き込まず、記録済みの不信頼を上書きできません。
判定基準は設定アンカーチェーンで、カレントディレクトリではありません：アンカー = 起動ディレクトリから上に向かって最も近い .tansr を含む祖先。アンカーまたはその祖先のいずれかが不信頼と記録されていれば、サブディレクトリが信頼済みでもゼロ実行で、フラグや環境変数でも上書きできません。信頼キーは実パス（realpath）で正規化されます。ジャンクション / シンボリックリンク / subst / 8.3 短縮名 / マップドドライブが同じワークスペースを指せば同じ記録です。実パス解決に失敗した場合はリテラルパスで扱い、信頼済みとは見なしません。過去に別名パスのリテラルで記録した信頼は、もう一度付与し直す必要があります。TUI の /cd も、/v2 セッション途中の cwd 切り替えも再判定しません。
プロジェクト層 http hook のリクエストヘッダーにある値全体の ${VAR} 記法は展開せず、リテラルのまま送信します（リポジトリ設定はあなたの環境変数を決して読みません。リクエストは拒否されずに送られます）。ユーザー層・管理層は従来どおり展開します。プロジェクト層プラグイン付属の hooks はプラグイン単位の信頼を既に通過しているため、このゲートを重ねて受けません。
プロジェクト層の MCP サーバーとプラグインも同じ規則（0.7.0 以降）：無人運転の 4 つの入口は、リポジトリが宣言する MCP サーバー / プラグインについても TUI が永続化した信頼記録だけを認めます。順序は永続化された拒否（定義のフィンガープリントで照合）> 永続化された許可 > TANSR_TRUST_PROJECT_MCP=1 / TANSR_TRUST_PROJECT_PLUGINS=1（記録がない、またはフィンガープリント不一致のときだけ有効）> 承認待ち。MCP 定義の変化は不一致とみなし、旧来のリテラルパス記録は拒否にのみ使い、許可には流用しません。環境変数だけで永続化された拒否を越えていたデプロイは 0.7.0 以降拒否されます——TUI で再度信頼を付与するか、その拒否記録を削除してください。tansr acp のプラグイン検出 / 信頼 / 署名検証は他の入口と共通で、未信頼のプラグインは一切ロードされず、通知は stderr に出ます（stdout はプロトコルフレームのみ）。
SDK 組み込み側（@tansr/sdk 0.14.0 以降）：createSession({ trustProjectHooks: true }) はホストがユーザーに代わって信頼を付与することを意味し、デフォルト false ではプロジェクト層 hooks はゼロ実行・hook.* イベントもゼロです。SDK は CLI の trust.json を決して読まず、信頼を永続化もしません。付与の責任は組み込み側が持ちます。信頼を付与せずプロジェクトに hooks がある場合、onWarning に project_hooks_untrusted が 1 件届きます（detail に cwd と検出した層 projectShared / projectLocal）。onWarning がなければ回復可能な turn.error { scope: 'sdk.notice' } に退避します。単一ターンの query() には信頼ビットがなく、プロジェクト層 hooks は決して有効になりません。

データの保持：どこに、どれだけ、誰が削除するか

ローカルマシン（CLI）

セッション、設定キャッシュ、使用量キュー、プロジェクトメモリは <storageRoot>/（デフォルト ~/.tansr。TANSR_STORAGE_ROOT または総ルート TANSR_USER_HOME でリダイレクト可能）に保存されます。プラットフォームにログイン後、新しいデータはアカウントごとに <storageRoot>/identities/<アカウント指紋>/ に分離されます。
セッションごとに 1 ディレクトリ：journal.jsonl（ハッシュチェーン）、meta.json、attachments/、上限超過の成果物 spill/。画像バイトは <storageRoot>/image-cache/<sessionId>/ にキャッシュされます。Shell の長い出力は <作業ディレクトリ>/.tansr/shell-output/ に、TTS 音声は <作業ディレクトリ>/.tansr/artifacts/<sessionId>/ に保存されます。
自動削除はされません。 クリーンアップは tansr sessions prune で行います（デフォルトは dry-run で一覧を表示するだけ。--apply で初めて削除。保持ポリシー --keep-days のデフォルト 90 と --keep-last のデフォルト 500 の和集合。当日のセッションと使用中のセッションは決して削除しない。壊れたディレクトリには --include-broken が必要）。tansr logout はアイデンティティストアのデータを削除しません。
セッション終了時の metrics.json にはカウントと比率だけがあり、パス、コマンド、ルールの原文は含みません。外部テレメトリはデフォルトで無効：現在のバージョンには外部への報告チャネルは一切存在しません。
プラットフォーム側は端末のセッション内容を保存せず、計量だけを行います。プラットフォームのセッションレジストリには 30 日間の非アクティブリースがあり、期限が来るとアーカイブされます。

セッションサービス（`@tansr/serve`）

セッション履歴は、あなたが設定した store ディレクトリの <dir>/agent-sessions/<endUserKey>/sessions/<sessionId>/ に保存されます。endUserKey はエンドユーザー id のハッシュであり、身元ではありません。コールド層をあなたのオブジェクトストレージにマウントでき、セグメントは平文の JSONL（圧縮）です——暗号化、キー管理、データの所在地、アクセス制御はあなたの責任です（policy.transform フック）。
メモリ上の短いウィンドウ：終了レコードは 30 分保持、アイドル 24 時間でディスクへ永続化。DELETE /v2/sessions/:id（/api/sessions/:id と同義）はクローズであり削除ではありません。保持期間を設定しなければ store はデフォルトで永続保存です。ストレージ保持期間のスキャン（日齢とユーザーごとの件数で休眠セッションを削除）は @tansr/serve 0.8.0 以降で提供（ファクトリオプション sessions.retention または 2 つの環境変数。保持期間とガバナンスを参照）。実際の削除は store.delete で行います。
0.14.0 以降、Idempotency-Key の受領証キャッシュはプロセス内のメモリ上にあり（ユーザーごと 256 件 / 全体 4 096 件 / 10 分）、endUserId ごとに分離され、プロセスとともに消えます。明示的に組み立てた SDK2 のアーカイブホストは「単一の認可ソース」ポリシーでアーカイブを保存し、バックアップではなく他所へ同期もせず、エントリの削除はホストが明示的に呼び出します。
構造化ログのフィールドにはトークンとメッセージ内容を決して含めません（0.13.0 以降のデフォルトレベルは warn で、どのレベルでも同様にマスキングされ、本文のキーは常に [redacted]）。メトリクスのラベルには sessionId / endUserId を決して含めません。
端末に下ろす権限要求フレームには完全なツール引数を決して載せず、ターゲットの概要だけを載せます。webhook のペイロードにはメッセージ内容と認証情報を決して載せません。

端末側

Android / iOS / HarmonyOS SDK は認証情報をキャッシュしません。ビュー状態はメモリにあります。sessionId をローカルに保存するか（コールドスタートで resume するため）はあなたが決めます——id だけを保存し、内容も認証情報も保存しません。

ローテーションと失効：各認証情報をどう替えるか

認証情報	替え方	影響範囲
PAT	コンソールで新しく 1 つ作成し、このマシンで `tansr init --fresh` を実行して再ログインし、その後コンソールで古い PAT を削除する	PAT は `tansr logout` では決して失効しない——他のデバイスがまだ同じものを使っている可能性がある
このマシンの派生アプリキー	`tansr init` を再実行すればローテーションして期限が延びる（期限が近いとセッション内に「キーの期限が近づいています」の通知が出る）。`tansr logout` はローカルを消去しリモートでの無効化を試みる。デバイスを紛失した場合はコンソールでそのデバイスキーを手動で無効化できる	各デバイスがそれぞれのキーを持ち（ホスト名 + デバイス id で命名）、互いに置き換わらない
アプリキー appkey	コンソールでローテーション（対応する `POST /v1/apps/:id/rotate`）。サーバー側の環境変数を更新してプロセスを再起動する	最終手段の全断：古い appkey は即座に無効になる
あるエンドユーザーのトークン	コンソールまたは管理 API でエンドユーザー単位に失効（`POST /v1/apps/:id/app-user-revocations`）。そのユーザーの既存トークンは即時すべて拒否される。あなたのシステムでそのユーザーのログイン状態を止めれば自然に供給が止まる（トークンの TTL は 60–86400 秒で、更新は存在しない）	そのユーザーにだけ影響
アプリ全体	コンソールでアプリを無効化	末端はすべて拒否
セッションサービス `/v1` Bearer	`TANSR_SERVE_TOKEN` / `--token` を替えて再起動	`/v1` 面の呼び出し側は同期が必要
webhook `secret`	受信側でまず新旧 2 つの値を同時に受け付け、次にセッションサービス側を替え、最後に古い値を撤去する	期間中の配信ロスはゼロ
あなた自身のログイン token（モバイル）	あなたのログインの仕組みに属する。SDK は 401 時に `authProvider` 経由で最大 2 回再取得し、それでも 401 なら終端状態に入ってあなたの明示的な再接続を待つ	トークンを更新しても 401 なら失効か設定ミスであり、一時的な揺れではない

プラットフォーム側でトークンの無効を引き起こすコードは 1 つだけです：unauthorized（401）。セッションサービスがこれを受け取ると、同じリクエスト内でキャッシュしたトークンを追い出し、再発行し、1 回再送します。端末側の SDK がこれを見たら、上記の 2 回で収束する手順を踏みます。他のコード（403、429、5xx）はいずれもトークンが壊れたことを意味しないので、それを理由に再発行しないでください。

クイック自己チェックリスト

tansr doctor：認証情報はキーチェーンにあるか、平文ファイルにあるか？localProviders のセクションはあなたの想定どおりか（プラットフォームモード / エスケープハッチ）？無人運転ベースラインに関する通知は出ていないか？
リポジトリで TANSR_APP_KEY / sk- / tansr_sk_ を一度 grep して、実際の値が入っていないことを確認する。
セッションサービスを 0.0.0.0 にバインドしているとき、/metrics は内部ネットワークにだけ公開されているか？store ディレクトリはローカルディスクで、共有されていないか？
あなたのトークン発行エンドポイントは自前のログイン状態の後にだけ発行し、endUserId は常にサーバー側のセッションから取得してリクエストボディを信頼していないか？x-tansr-end-user はゲートウェイだけが書き込んでいるか？
--v2 デプロイでまだ --legacy-v1 / TANSR_SERVE_LEGACY_V1 を有効にしていないか？ログに server.deprecated_option があれば取り除く予定を立てるべきで（1.0.0 で削除）、承認の送付は POST /api/approvals/:id/credential に替えます。
--host-module-sha256 はデプロイパイプラインが .cjs 成果物と一緒に生成しているか、リリース時に手計算していないか？
コールド層オブジェクトストレージのライフサイクルルールと暗号化は設定済みか？