ticktick-mcp

TickTick タスク管理のための MCP サーバーです。TickTick v2 API を介してタスクの作成、更新、完了、移動、フィルタリングを行います。フィールドを保持する更新、曜日の日付検証、書き込み後読み取りの検証、冪等な完了追跡を備えています。

Claude Code や他の MCP クラアント向けに設計されています。

非公式です。TickTick Ltd. とは関係ありません。ticktick-py (MIT) 上に構築されています。

特長

• 完全なタスクライフサイクル - 作成、更新、完了、移動、サブタスク化、削除

• フィールド保持の更新 - ticktick_update_task はタスクを再取得し、設定したフィールドのみを上書きします。指定しなかったフィールドが API 側で消去されることはありません

• 曜日の検証 - 日付を設定する呼び出しは必ず曜日を確認するため、日付のズレによる誤りをサーバーに届く前に検出します

• 書き込み後読み取りの検証 - 作成/更新時にタスクが読み直しされ、サーバーの応答が一致しない場合は _verification_warnings が表示されます

• 簡潔な一覧表示 - 一覧系ツールはデフォルトで簡潔なビューを返すため、大きなプロジェクトでも MCP の結果サイズ上限を超えません（下記参照）

• 最新の読み取りを維持 - 読み取り系ツールは必要な時にサーバーの状態を再同期するため、他のデバイスの TickTick アプリで行った更新が再起動なしで反映されます

• 完了の追跡 - 完了したタスクを処理済みにすることで、エージェントが各タスクを正確に一度だけ確認できます

Related MCP server: ticktick-mcp-server

要件

• Python 3.13+

• uv（推奨 - 下記のインストール注記を参照）

• TickTick のアカウント

• OAuth 認証情報用に登録した TickTick アプリ（無料 - developer.ticktick.com）

インストール

git clone https://github.com/partymola/ticktick-mcp
cd ticktick-mcp
uv sync

これにより .venv が作成され、uv.lock からインストールされます。コンソールスクリプトは .venv/bin/ticktick-mcp、Windows では .venv\Scripts\ticktick-mcp として配置されます。以下のすべてのコマンドでは POSIX 名で表記しています。

pip install . でも動作します。このサーバーが必要とする ticktick-py のフォークは dependencies 内に直接 Git 参照として固定されており、pip と uv の両方でそのまま使用されます。uv sync を推奨するのは、解決をやり直さずに uv.lock の正確なバージョンをインストールできるためです。

認証情報の設定

TickTick へのサインインには2つが必要です: OAuth アプリ（クライアント ID + シークレット）と、ご自身のアカウントのログイン情報です。

1. developer.ticktick.com でアプリを登録します。リダイレクト URL は http://localhost:8080/redirect に設定してください。クライアント ID(Client ID) と クライアントシークレット(Client Secret) を控えておきます。

2. テンプレートをサーバーが読み取るディレクトリにコピーし、内容を入力します:

   mkdir -p ~/.config/ticktick-mcp && cp .env.example ~/.config/ticktick-mcp/.env

   TICKTICK_CLIENT_ID=your_client_id
   TICKTICK_CLIENT_SECRET=your_client_secret
   TICKTICK_REDIRECT_URI=http://localhost:8080/redirect
   TICKTICK_USERNAME=your_ticktick_email
   TICKTICK_PASSWORD=your_ticktick_password

3. このファイルにはアカウントのパスワードが平文で保存されます。また、サーバーはこのファイルを作成しないため、ご自身でアクセスを制限してください。POSIX では:

   chmod 700 ~/.config/ticktick-mcp
   chmod 600 ~/.config/ticktick-mcp/.env

   これらは POSIX のアクセス権ビットであり、Windows では効果がありません。Windows でのアクセスは、親ディレクトリからファイルが継承する ACL に従います。この2つのコマンドに対応する Windows の同等コマンドは、ここでは説明しません。

   また、その隣に作成される2つのトークンファイルは所有者のみのアクセス権で作成され、サーバーが作成する設定ディレクトリも同様です。ただし、既に存在する設定ディレクトリはそのまま残されます。これらも POSIX の権限モードであり、Windows でも設定されますが、Windows では誰が何を読むことができるかを絞ることはありません。

サーバーを登録する前に、一度だけターミナルで認証してください:

.venv/bin/ticktick-mcp auth

ブラウザが開き、リダイレクト先の URL を貼り戻すよう求められ、その後終了します。トークンは .env の隣に .token-oauth としてキャッシュされ、以降の起動時に再利用されます。TickTick はリフレッシュトークンを発行しないため、トークンの期限切れ時にこの手順を繰り返します - 同じコマンドをもう一度実行してください。

この手順を MCP サーバー内で行わないでください。プロンプトは標準入力を読み取るためです。stdin サーバーの標準入力は JSON-RPC チャネルであるため、未認証の最初のツール呼び出しでホスト上でブラウザが開き、ブロックされます。コンテナ内では完了させられせん - ホスト上で auth を実行し、設定ディレクトリをマウントしてください。

ユーザー名とパスワードの部分には個別の手順は不要です。サーバーは最初のツール呼び出しで遅れてログインし、そのセッショントークンを .token-v2 としてキャッシュするため、毎回の起動で資格情報を再送信する必要はありません。

サーバーが .env を探す順序は次のとおりです: --dotenv-dir <path> 引数、次に TICKTICK_MCP_DOTENV_DIR 環境変数、最後に ~/.config/ticktick-mcp/ です。.env が見つからない場合、サーバーは直接 TICKTICK_* 環境変数にフォールバックします。これはコンテナや CI での使用に便利です。

プライバシーと非公式 API

TickTick の資格情報はローカルの .env(または環境変数)にのみ保存され、TickTick 自体のサーバーにのみ送信されます。開発者や第三者に送信されることはありません。このサーバーが読み書きをするのは、あなた自身のアカウントのみです。

このサーバーは公式の TickTick ではなく、TickTick の非公式 v2 API(ticktick-py 経由)を使用しています。これには YouTube という意図的な選択。公式 API には完了済みタスクの一覧エンドポイント、タグ、プロジェクトをまたいだタスク一覧がありません。これらはすべてこのサーバーが依存しているものです。全容の合理的な根拠、リスクのトレードオフ、再検討の材料については docs/why-not-the-official-api.md を参照してください。

Claude Code との連携

claude mcp add -s user ticktick -- /path/to/ticktick-mcp/.venv/bin/ticktick-mcp --dotenv-dir /path/to/config

--dotenv-dir は、.env が ~/.config/ticktick-mcp/ に置かれている場合、または TICKTICK_* 変数を環境で与える場合には省略できます。

その後、Claude に次のように依頼してみてください:

• "今週の TickTick リストに何がありますか?"

• "金曜日の午前9時に歯医者に電話するタスクを追加して。"

• "買い物タスクを完了にして。"

• "予算タスクを Finance プロジェクトに移動して。"

Docker

イメージは ghcr.io/partymola/ticktick-mcp に公開されています。タグは v 接頭辞(:vX.Y.Z)を持ち、:latest は最新のリリースに追従します。

まずブラウザのあるマシンで認証し、そのディレクトリをマウントします。 これが唯一の方法であり、docker run -it でも同様です。基盤のライブラリがブラウザを自動的に開き、URL を決して出力しないため、ブラウザのないコンテナから持ち替える情報はありません。その後は標準入力でその URL を待受診ますが、stdio サーバーの標準入力は JSON-RPC チャネルです。つまり、トークンのキャッシュがないディレクトリで起動したコンテナも正常には失敗せず、クライアントの要求を役立てて、到着しない入力を待ち続けることになります。

認証にはソースからインストール(Install)と、 認証情報 が必要です。認証を実行できる公開原稿はありません。pip install ticktick-mcp はしないでください。 PyPI ではその名前は、ほぼ同じ説明文を持つ無関係のプロジェクトに属します。

.venv/bin/ticktick-mcp auth       # once, on the host, in a terminal

claude mcp add -s user ticktick -- \
  docker run --rm -i --user $(id -u):$(id -g) \
  -v ~/.config/ticktick-mcp:/data \
  ghcr.io/partymola/ticktick-mcp:latest

-i は必須です - サーバーは stdin / stdout で JSON-RPC を利用するためです。

--user を指定するのは、コンテナがデフォルトで root として実行されるためで、マウントしたディレクトリに書き込むものすべてが root 所有になってしまいます。その結果、ホスト側の ticktick-mcp はセッショントークンキャッシュを更新できなくなり、起動時にスロットル付きの再度ログインにフォールバックします。後でホスト上で auth を再実行する必要があります。OAuth トークンにはリフレッシュがないため、期限切れの度に auth を繰り返します。

認証済みのディレクトリをマウントしてください。空のボリュームはマウントしないでください。 /data には .env、キャッシュされた OAuth トークン、v2 セッショントークン、完了追跡データベースが保持されます。新しいボリュームにはそれらがなく、パスワード再サインインのフォールバックは 15〜30 分のロックアウトに間引かれます。

.env をディスクに保存したくない場合は、代わりに環境変数で資格情報を渡します。マウントは引き続き必要です - そこには .env だけでなくトークキャッシュも含まれるため:

docker run --rm -i --user $(id -u):$(id -g) \
  -v ~/.config/ticktick-mcp:/data \
  -e TICKTICK_CLIENT_ID -e TICKTICK_CLIENT_SECRET \
  -e TICKTICK_USERNAME -e TICKTICK_PASSWORD \
  ghcr.io/partymola/ticktick-mcp:latest

各変数を値なしで指定するとシェルから渡されるため、コマンドラインやシェル履歴に秘密情報が表示されません。これらの変数はマウントされた .env より優先されます: .env は override 付きで読み込まれないため、環境に既に設定されている値が勝ります。認証には、ホスト側でこれらの変数をエクスポートしておく必要があります。auth は .env も設定されないためです。

CLI

ticktick-mcp                       Start the MCP server (stdio transport)
ticktick-mcp --dotenv-dir PATH     Directory holding the .env file
ticktick-mcp --version             Print the installed package version

auth は唯一の他のサブコマンドで、ブラウザでのステップをサーバーではなくターミナルで実行できるようにします。タスクに関わる処理はすべて、以下の MCP ツールを使って行われます。

MCP ツール

プロジェクト: 名前または ID

プロジェクト ID を受け取るすべてのツールは、プロジェクトの名前も受け取ります - ticktick_create_task、ticktick_get_tasks_from_project、ticktick_update_task、ticktick_move_task、ticktick_delete_tasks、ticktick_filter_tasks、および両方の完了追跡ツールです:

ticktick_create_task(title="Renew insurance", project_id="Home Admin")

名前は大文字と小文字を区別せず、周辺の空白を無視して一致し、"Inbox" は inbox に解決されます。ID は従来通り動作し、常に名前より優先されるため、今日動作しているものは何も変わりません。

新たなエラーは曖昧さだけです。2つのプロジェクトが同名の場合、どちらかを選ばずに呼び出しは失敗し、両方の ID を名指しします。推測すると、見事に知らないような場所にタスクをまとめてしまうからです。それ以外にサーバーで解決できない部分は、これまでと同様に API にそのまま渡されます。# ticktick-mcp

TickTickのタスク管理のためのMCPサーバーです。TickTick v2 APIを介して、タスクの作成、更新、完了、移動、フィルタリングを行います。フィールドを保持する更新、曜日の日付検証、書き込み後の読み取り検証、冪等な完了追跡を備えています。

Claude Code や他の MCP クライアント向けに設計されています。

非公式です。TickTick Ltd.とは関係ありません。ticktick-py（MIT）に基づいて構築されています。

機能

• 完全なタスクライフサイクル - 作成、更新、完了、移動、サブタスク化、削除

• フィールドを保持する更新 - ticktick_update_task はタスクを再取得し、設定したフィールドのみを重ね合わせます。省略したフィールドが API によって消去されることはありません

• 曜日の検証 - 日付を設定するすべての呼び出しで曜日を確認し、1日ずれた日付のミスをサーバーに届く前に検出します

• 書き込み後の読み取り検証 - 作成/更新後にタスクを読み直し、サーバーの応答が一致しない場合は _verification_warnings を表示します

• コンパクトな一覧表示 - 一覧ツールはデフォルトで簡潔なビューを返すため、大きなプロジェクトでも MCP の結果サイズ上限を超えません（下記参照）

• 最新の読み取り - 読み取りツールは要求に応じてサーバー状態を再同期するため、他のデバイスの TickTick アプリで行った編集が再起動なしに反映されます

• 完了の追跡 - 完了したタスクを「処理済み」とマークすることで、エージェントが各タスクをちょうど一度ずつ確認できます

必要条件

• Python 3.13+

• uv（推奨 - 下記のインストール注参照）

• TickTickアカウント

• OAuth 認証情報用に登録済みの TickTick アプリ（無料 - developer.ticktick.com）

インストール

git clone https://github.com/partymola/ticktick-mcp
cd ticktick-mcp
uv sync

これにより .venv が作成され、uv.lock からインストールされます。コンソールスクリプトは .venv/bin/ticktick-mcp、Windows では .venv\Scripts\ticktick-mcp に配置されます。以下のすべてのコマンドは POSIX 形式で表記しています。

pip install . でも動作します。このサーバーが必要とする ticktick-py のフォークは dependencies 内で直接 Git 参照として固定されており、pip と uv の両方がそれを尊重します。uv sync が推奨されるのは、uv.lock 内の正確なバージョンを再解決せずにインストールするためです。

認証情報

TickTick へのサインインには2つのものが必要です: OAuth アプリ（クライアント ID とシークレット）と、ご自身のアカウントのログインです。

1. developer.ticktick.com でアプリを登録します。リダイレクトURI を http://localhost:8080/redirect に設定します。クライアント ID と クライアントシークレット をメモします。

2. テンプレートをサーバーが読み取るディレクトリにコピーし、内容を記入します:

   mkdir -p ~/.config/ticktick-mcp && cp .env.example ~/.config/ticktick-mcp/.env

   TICKTICK_CLIENT_ID=your_client_id
   TICKTICK_CLIENT_SECRET=your_client_secret
   TICKTICK_REDIRECT_URI=http://localhost:8080/redirect
   TICKTICK_USERNAME=your_ticktick_email
   TICKTICK_PASSWORD=your_ticktick_password

3. このファイルにはアカウントのパスワードが平文で保存されます。サーバーはこのファイルを作成しないため、ご自身でしっかりと保護してください。POSIX では:

   chmod 700 ~/.config/ticktick-mcp
   chmod 600 ~/.config/ticktick-mcp/.env

   これらは POSIX のモードビットであり、Windows では何も行いません。Windows でのアクセスは、親ディレクトリからファイルが継承する ACL に従います。この2つのコマンドに相当する Windows の方法はここでは説明していません。

   その隣にある2つのトークファイルは、所有者のみがアクセスできる状態で作成されます。サーバーが作成する設定ディレクトリも同様ですが、既に存在する設定ディレクトリはそのまま変更されません。これらも POSIX モードであり、Windows でも設定されますが、Windows では読み取りの範囲を狭めることはありません。

サーバーを登録する前に、ターミナルで一度だけ認証してください:

.venv/bin/ticktick-mcp auth

これによりブラウザが開き、表示された URL を貼り付け戻すよう求められ、その後終了します。トークンは .env の隣に .token-oauth としてキャッシュされ、以降の起動では再利用されます。TickTick はリフレッシュトークンを発行しないため、トークンが期限切れになったら繰り返しに - 同じコマンドを再度実行してください。

この手順を MCP サーバー内で実行してはいけません。プロンプトは標準入力から読み取るため、stdio サーバーではその標準入力が JSON-RPC チャネルになります。そのため、未認証の最初のツール呼び出しはホスト上でブラウザを開き、ブロックされます。コンテナ内では完了できません - ホスト上で auth を実行し、設定ディレクトリをマウントしてください。

ユーザー名/パスワードの部分は、別途手順は不要です。サーバーは最初のツール呼び出しで遅延的にログインし、そのセッショントークンを .token-v2 としてキャッシュするため、毎回の起動で認証情報を再送信することはありません。

サーバーは次の順序で .env を探します: --dotenv-dir <path> 引数、次に TICKTICK_MCP_DOTENV_DIR 環境変数、その後 ~/.config/ticktick-mcp/ です。.env が見つからない場合は、直接 TICKTICK_* 環境変数にフォールバックします。これはコンテナ/CI での使用に便利です。

プライバシーと非公式 API

あなたの TickTick 認証情報はローカル .env（または環境）にのみに存在し、TickTick 自体のサーバーにのみ送信されます - 開発者や第三者に送信されることは一切ありません。サーバーが読み書きするのは、あなた自身のアカウントのみです。

このサーバーは公式の Open API ではなく、TickTick の非公式 v2 API（ticktick-py 経由）を使用しています。これは意図的な選択です。公式 API には、完了済みタスクの一覧エンドポイント、タグ、プロジェクトをまたぐタスク一覧がありません。これらすべてこのサーバーが依存している機能です。完全な根拠、リスクのトレードオフ、再検討のきっかけについては、docs/why-not-the-official-api.md を参照してください。

Claude Code に登録

claude mcp add -s user ticktick -- /path/to/ticktick-mcp/.venv/bin/ticktick-mcp --dotenv-dir /path/to/config

--dotenv-dir は、.env が ~/.config/ticktick-mcp/ にある場合、または TICKTICK_* 変数を環境変数で提供する場合は省略できます。

その後、Claude に次のように質問してみてください:

• "今週の TickTick リストには何がある?"

• "金曜日の午後9時に歯医者に電話するタスクを追加して。"

• "買い物タスクを完了にして。"

• "予算タスクを Finance プロジェクトに移動して。"

Docker

イメージは ghcr.io/partymola/ticktick-mcp に公開されています。タグには v 接頭辞（:vX.Y.Z）が付き、:latest は最新のリリースに追従します。

先にブラウザのあるマシンで認証し、そのディレクトリをマウントしてください。 これが唯一の方法であり、docker run -it の場合も同樣です。基盤ライブラリはブラウザ自体を開き、URL を絶対に表示しません。そのため、ブラウザのないコンテナからコピーできるものはありません。その後、その URL を標準入力で待ちますが、stdio のサーバーではそれが JSON-RPC チャネルになります。つまり、キャッシュされたトークンのないディレクトリで起動したコンテナは明示的に失敗するわけでもなく、クライアントのリクエストを受け続けながら、待っても到着しない入力を待ち続けます。

認証には、ソースからのインストール(インストール)と 認証 情報 が必要です - 認証を実行するための公開パッケージはありません。pip install ticktick-mcp をしないでください: PyPI 上のその名前は、ほぼ同一の説明を持つ無関係なプロジェクト帰属です。

.venv/bin/ticktick-mcp auth       # once, on the host, in a terminal

claude mcp add -s user ticktick -- \
  docker run --rm -i --user $(id -u):$(id -g) \
  -v ~/.config/ticktick-mcp:/data \
  ghcr.io/partymola/ticktick-mcp:latest

-i は必須です - サーバーは標準入力と標準出力で JSON-RPC を話すためです。

--user は、コンテナがデフォルトで root として実行されるためです。マウントされたディレクトリにコンテナが書き込むものはすべて root 所有となり、その結果、ホスト側の ticktick-mcp がセッショントークンキャッシュを更新できなくなります。そして、起動のたびにスロットルされたサインオンにフォールバックします。ホスト上で再度認証を実行することになります。OAuth トークンはリフレッシュがないため、auth は有効期限のたびに繰り返します。

認証済みのディレクトリをマウントしてください。決して空のボリュームをマウントしないでください。 /data には .env、OAuth トークンキャッシュ、v2 セッショントークン、完了追跡データベースが保存されます。新しいボリュームにはそれらがなく、パスワードによるサインオンのフォールバックは15〜30分のロックアウトにスロットリングされます。

.env をディスクに一切置きたくない場合は、資格情報を環境変数として渡してきます。マウントはまだ必要です - そこには .env だけでなくトークンキャッシュも保持されるため:

docker run --rm -i --user $(id -u):$(id -g) \
  -v ~/.config/ticktick-mcp:/data \
  -e TICKTICK_CLIENT_ID -e TICKTICK_CLIENT_SECRET \
  -e TICKTICK_USERNAME -e TICKTICK_PASSWORD \
  ghcr.io/partymola/ticktick-mcp:latest

各変数を値なしで指定することで、シェルからそのまま渡されるため、コマンドやコマンドや環境シェル履歴に秘密が表示されません。これらはマウントされた .env に優先します: ファイルは override なしで読み込まれるため、既に環境に設定されたものが勝ちます。認証には、ホスト上でそれらの変数をエクスポートしておく必要があります。auth には読み取り可能な .env がないためです。

CLI

ticktick-mcp                       Start the MCP server (stdio transport)
ticktick-mcp --dotenv-dir PATH     Directory holding the .env file
ticktick-mcp --version             Print the installed package version

auth はもう唯一の別のサブコマンドであり、ブラウザのステップがサーバー内ではなく、ターミナルで行われるために存在します。すべてのタスク操作は、以下の MCP ツールを通じて行われます。

MCP ツール

| ツール | 説明 |

プロジェクト: 名前または ID

プロジェクト ID を受け取るすべてのツールは、プロジェクトの名前も受け取ります - ticktick_create_task、ticktick_get_tasks_from_project、ticktick_update_task、ticktick_move_task、ticktick_delete_tasks、ticktick_filter_tasks、および両方の完了追跡ツール:

ticktick_create_task(title="Renew insurance", project_id="Home Admin")

名前は大文字と小文字を区別せず、周囲の空白を無視して一致し、ticktick は自分の受信トレイに解決されます。ID は引き続きそのまま動作し、常に優先されるため、現在動いているものの動作は変わりません。

新しいエラーは曖昧さだけです: 2つのプロジェクトが同じ名前を持つ場合、呼び出しは失敗し、片方を選ぶのではなく両方の ID を挙動します。 推測すると、タスクを見つかるとは思えない場所に保存することになるからです。サーバーが解決できない他のものは、従来どおり API にそのまま渡されます。

2つの完了追跡ツールは例外で、確認できないプロジェクト参照は渡すのではなく拒否します。なぜなら、その値がローカルデータベースが書き込まれるキーだからです。解決できない参照は、後でIDで検索しても見つからない行を書き込むことになります。プロジェクト一覧を更新して確認できない場合は、プロジェクトが存在しないと主張する代わりに、その旨を報告します（outcome: "project_list_unverifiable"）。

タスクの一覧表示：デフォルトでコンパクト

一覧を返すツール（ticktick_get_tasks_from_project と ticktick_filter_tasks）は、デフォルトで detail="compact" になります。コンパクト出力は、ブラウジングに関連するフィールド（id、projectId、title、dueDate、startDate、priority、status、isAllDay、timeZone、tags）に加えて contentPreview（content の最初の約200文字）を保持し、重い content/desc/チェックリストのitemsブロブとかさばる同期メタデータを削除します。これにより、大規模なプロジェクトでもMCPの結果サイズ上限内に収まり、クライアントが結果をディスクにあふれさせる必要がなくなります。キーワード検索は引き続き title と contentPreview に対して機能します。

• 完全なオブジェクトが必要ですか？detail="full" を渡してください。

• 1つのタスクの完全なコンテンツが必要ですか？ticktick_get_by_id を使用してください。

• タスクの編集： まず ticktick_get_by_id で完全なオブジェクトを取得し、その後 ticktick_update_task で全フィールドを送信してください。TickTick APIは更新で省略されたフィールドを消去するため、コンパクト出力を更新に使用してはいけません。

コンパクトな結果がそれでもサイズ上限を超える場合は、期限が最も近いタスクが返され、最後の _truncation_note 要素で省略された数を報告します。何も黙って削除されることはありません。残りには、より狭い ticktick_filter_tasks クエリ、detail="full"、または ticktick_get_by_id を使用してください。

最新性：読み取りは最新の状態を維持

サーバー実行中に、TickTickアカウントは他のデバイスのアプリから編集される可能性があります。読み取りが古くならないように、読み取りツールはオンデマンドでサーバー状態を再同期します。これはウィンドウあたり最大1回に制限されています（デフォルト15秒、TICKTICK_MCP_SYNC_TTL_SECONDS で上書き可能）。別の場所で行われた変更は、そのウィンドウ内で表示されます。ticktick_sync を呼び出すと、即時の更新を強制して現在のタスク/プロジェクト数を取得できます。同期が失敗した場合は、エラーにする代わりに最後に認識された状態を提供します。ただし、ticktick_get_all は例外で、毎回更新し、代わりに失敗を報告します。全量ダンプは、古い回答を静かに提供する場所としては不適切だからです。

設定

タスクの変更からの保護

一部のタスクは、エージェントが何を要求されても決して変更してはなりません。それらのIDを TICKTICK_MCP_PROTECTED_TASK_IDS にリストしてください：

TICKTICK_MCP_PROTECTED_TASK_IDS="60ca9dbc8f08516d9dd56324,60ca9dbc8f08516d9dd56325"

ticktick_update_task、ticktick_complete_task、ticktick_delete_tasks、ticktick_move_task、ticktick_make_subtask は、保護されたタスクを指定する呼び出しを拒否し、outcome: "protected_task" を返します。タスクを読み書きするリクエストは送信されません。保護されたタスクを含む一括削除は、部分適用ではなく全体が拒否されます。部分的な削除は取り消せないためです。

TickTickは削除と移動をサブタスクに伝播させるため、delete、move、make_subtask は、指定したタスクの親またはサブタスクが保護されたタスクである場合も拒否します。このチェックは最初にローカル状態を更新するため、保護が設定されている場合、削除・移動・サブタスク作成のたびに1リクエスト追加されます。更新に失敗した場合は、更新できないスナップショットで保護されたサブタスクを排除できないため、outcome: "protection_unverifiable" を返します。変数が未設定の場合は追加の作業は一切行われません。IDは周囲の空白、引用符、大文字小文字を無視して照合されます。保護されたタスクの読み取りは常に機能します。

認証情報（TICKTICK_CLIENT_ID、TICKTICK_CLIENT_SECRET、TICKTICK_REDIRECT_URI、TICKTICK_USERNAME、TICKTICK_PASSWORD）は .env ファイルから読み取られ、存在しない場合は環境変数から直接読み取られます。

データの安全性

pre-commitフック（scripts/check-no-data.sh）は、データベース、認証情報、大きなファイルの誤コミットを防止します - *.db とそのバックアップ、config/ 以下の .gitkeep と *.example* を除くすべて、100KBを超えるファイル（uv.lock を除く）。クローン後にインストールしてください：

ln -sf ../../scripts/check-no-data.sh .git/hooks/pre-commit

貢献

開発環境のセットアップ、テストワークフロー、pre-commitフックについては CONTRIBUTING.md を参照してください。変更履歴は CHANGELOG.md に記録されています。

ライセンス

LICENSE（GPL-3.0-or-later）