dosya CLIの設定を確認する
使用中の設定を探し、保存されたキーを表示せずにAPIエンドポイントとワークスペースを確認し、コマンド実行前に環境変数やフラグによる上書きを特定します。
最終確認日
スクリーンショットは英語版の画面です。
想定外のアカウント、ワークスペース、サーバーを調べる前にCLIの設定を確認してください。安全なコマンドでは保存されたAPIキーが伏せられ、後の操作に影響するAPIベース、既定のワークスペース、同期オプションが表示されます。
手順
dosya config path
dosya config get
dosya config get --json
config pathは通常~/.dosya/config.jsonを表示します。XDG_CONFIG_HOMEで変更されている場合は$XDG_CONFIG_HOME/dosya/config.jsonを表示します。config getは次のサポート対象の値を表示します。
api_base:RESTリクエストに使用するサーバー。default_workspace:明示的なコンテキストのないコマンドが引き継ぐワークスペース。sync_delta:trueで対象の同期変更に対するブロック単位の差分アップロードを有効にします。sync_parallel:並行する同期転送数。既定は8、最大は16です。
引数なしの形式とJSON形式ではトークンは表示されません。保存されたキーがある場合はapi_key: "<redacted>"が返されます。不明な名前にはUnknown config key: NAME. Available keys: api_base, default_workspace, sync_delta, sync_parallelが返されます。

使用されるエンドポイントと認証情報を確認する
既定のAPIベースはhttps://api.dosya.devです。エンドポイントは次の順に優先されます。
- プロセス環境の
DOSYA_API_BASE。 - 保存された
api_baseの値。 - 組み込みの本番環境の既定値。
認証情報の優先順位は異なります。
- コマンドの
--keyまたは-k。 - 環境変数の
DOSYA_API_KEY。 - 設定ファイルの
api_key。
値の内容を表示せずに、シェルが保存値を上書きしているか確認してください。
if test -n "${DOSYA_API_KEY+x}"; then echo 'DOSYA_API_KEY is set'; else echo 'DOSYA_API_KEY is not set'; fi
if test -n "${DOSYA_API_BASE+x}"; then printf 'DOSYA_API_BASE=%s\n' "$DOSYA_API_BASE"; else echo 'DOSYA_API_BASE is not set'; fi
dosya whoami
dosya whoamiで実際に使われる認証情報をテストできます。優先されたキーとエンドポイントで接続したアカウントの識別情報が表示されます。保存した認証でサインインできても、同じホームフォルダーまたはXDG_CONFIG_HOMEを使わない別のシェルがそのファイルを読み取るとは限りません。
ワークスペースの解決を確認する
dosya config get default_workspace
dosya ls
通常のパス参照では、ws_ID:path、--workspace、default_workspaceの順に優先されます。既定値は以降のCLIコマンドにのみ影響し、ブラウザのアクティブなワークスペースは変更しません。一覧の内容に覚えがない場合は、dosya ls --jsonで確認したworkspace_idとdosya workspace listが返すIDを比較してください。
サポートされる値だけを変更する
dosya config set default_workspace ws_REPLACE_ME
dosya config set api_base https://api.dosya.dev
dosya config set sync_delta true
dosya config set sync_parallel 12
config setには既存の設定が必要です。存在しない場合はNot authenticated. Run: dosya auth loginが返されます。値は文字列として書き込まれます。コンテキストの変更後はconfig get KEYと安全なコマンドを1つ再実行してください。マシンの既定値が変わっても転送先を固定したい場合は、デプロイスクリプトで明示的に--workspaceを使用してください。
config setでapi_keyを手動編集しないでください。このキーは許可されたキーから意図的に除外されています。保存された認証にはdosya auth login、外部から渡すシークレットにはDOSYA_API_KEYを使用してください。

設定ファイルを保護する
このファイルには保存されたAPIキーが平文で含まれます。Unix系システムでは、サインイン時に0700フォルダー内にモード0600で作成されます。バックアップ、コピー、アーカイブによってファイルのアクセス権が緩くなった場合、CLIはパスと推奨されるchmod 600の修正を示す警告を出します。Windowsではこのモードチェックは行われません。
未加工のファイルをサポートリクエストに添付しないでください。代わりにdosya config get --json、dosya whoami --json、キーを削除したコマンドライン、終了コード、秘密情報を除いたエラー出力を使用してください。デバッグログにはDOSYA_API_KEYや--keyの実際の値を含めないでください。
不一致を解決する
config getが設定なしと表示する。 現在のホームフォルダーとXDG_CONFIG_HOMEを確認し、この環境でdosya auth loginを実行してください。
表示されたapi_baseは本番環境だが、リクエストが別のサーバーに届く。 ファイルより優先されるDOSYA_API_BASEを確認してください。
whoamiに別のアカウントが表示される。 コマンドラインでのキーの上書きを外すか、プロセスが引き継いだDOSYA_API_KEYを確認してください。
正しいアカウントに別のワークスペースが表示される。 保存された既定値を変更する前に、ws_ID:パスのプレフィックスと--workspaceを確認してください。
api_baseを変更すると認証できない。 APIキーは発行元のサービスに属します。信頼できるdosya環境から別のエンドポイントが明示的に提供された場合を除き、https://api.dosya.devを元に戻してください。
期待される結果
設定ファイルの場所が分かり、キーは伏せられたままです。dosya whoamiと読み取り専用の一覧表示で、使用されるエンドポイント、アカウント、ワークスペースを確認できます。本番コマンドの実行前に、環境変数とコマンドラインによる上書きが意図的なものか確認し、不要なものは外します。
関連ガイド
この記事は役に立ちましたか?
評価の結果を読み込んでいます…
投票すると、回答を変更できるように、必要な投票用Cookieが最長180日間保存されます。
質問と回答
このガイドの手順について質問できます。質問は確認後に公開されます。
公開の質問には、アカウントの詳細、認証情報、非公開ファイルを含めないでください。これらについては 非公開サポート をご利用ください。
質問を読み込んでいます…
dosyaアカウントにサインインすると、質問を投稿できます。