Tugas Terjadwal Claude Code Desktop: Otomasi Lokal

Saya menyiapkan code review harian untuk pukul sembilan pagi, menutup laptop selama akhir pekan, dan kembali pada Senin ke sebuah review yang berjalan pukul tujuh malam itu dan dengan rajin meringkas commit tiga hari seolah semuanya milik hari itu. Tugasnya bekerja persis sesuai desain. Prompt sayalah yang mengandaikan sebuah fakta tentang jam yang tidak pernah dijanjikan scheduler-nya.

Tugas terjadwal lokal adalah opsi tengah antara loop sesi dan routine cloud, dan batasannya cukup spesifik untuk dirancang mengelilinginya. Tulisan ini membahas apa yang membedakannya dari dua lainnya, opsi jadwal dan offset deterministiknya, aturan penyusulan dan cara menulis prompt yang selamat darinya, tarian permission yang mencegah run mandek, serta di mana tugasnya benar-benar tersimpan di disk.

Lokal atau remote, dari halaman yang sama

Halaman routines pada aplikasi Desktop membuat keduanya, dan itu praktis sekaligus sebentar membingungkan. Tugas lokal berjalan di mesin Anda dengan akses langsung ke file dan perkakas Anda, dan hanya menyala selama aplikasinya terbuka dan komputernya menyala. Routine remote berjalan di cloud bahkan ketika komputer Anda mati, dan bisa pula menyala pada panggilan API atau event GitHub — tetapi bekerja dari clone segar alih-alih working directory Anda.

Perbedaan itulah seluruh dasar untuk memilih. Kalau tugasnya perlu melihat pekerjaan yang belum di-commit, sebuah checkout lokal, atau perkakas yang hanya ada di mesin Anda, ia harus lokal. Kalau ia harus terjadi dengan andal terlepas dari apakah Anda ada di meja, ia harus remote. Sangat sedikit yang berada di antaranya.

Jadwal, dan offset yang bukan bug

Picker-nya mencakup kasus umum dan bahasa biasa mencakup sisanya, dan itu pembagian yang bagus. Yang layak diketahui adalah tugas Anda tidak akan menyala persis pada menit yang Anda pilih, dan itu memang disengaja.

# Presets in the Schedule control:
#   Manual     no schedule; only runs when you click Run now
#   Hourly
#   Daily      time picker, defaults to 9:00 AM local
#   Weekdays   as Daily, skipping Saturday and Sunday
#   Weekly     time picker plus a day picker

# For anything the picker does not offer — every 15 minutes,
# the first of each month, a single run at a future time — just
# ask Claude in any Desktop session, in plain language:
#
#   "schedule a task to run all the tests every 6 hours"
#   "set up a daily code review that runs every morning at 9am"
#   "remind me at 3pm tomorrow to check the deploy"
#
# The last one creates a ONE-TIME task that disables itself
# after it fires.

# Each task gets a delay of a few minutes after its scheduled
# time to stagger API traffic. The delay is DETERMINISTIC — the
# same task always starts at the same offset.

Tulis prompt-nya untuk saat ia mungkin benar-benar berjalan

Inilah bagian yang saya harap sudah saya baca sebelum menyiapkan tugas pertama saya. Perilaku penyusulannya masuk akal — satu run alih-alih enam, untuk waktu terlewat yang paling akhir alih-alih yang tertua — dan itu berarti jarak antara waktu terjadwal dan eksekusi sebenarnya bisa sangat jauh.

# Write the prompt for the time it might ACTUALLY run.
#
# Desktop checks, on app start or machine wake, whether a task
# missed any runs in the last seven days. If so it starts
# exactly ONE catch-up run for the most recently missed time
# and discards everything older. A daily task that missed six
# days runs once on wake.
#
# So a task scheduled for 9am can genuinely execute at 11pm.

# A prompt that survives that:

Review commits pushed to main today.
If it is after 5pm, skip the review and post a one-line
summary of what was missed instead.
Do not review commits from previous days.

# Guardrails belong in the prompt, not in your assumptions
# about when the schedule fires.

Di mana sebuah run muncul, dan apa yang bisa dilakukannya

Ketika sebuah tugas menyala, Anda mendapat notifikasi desktop dan sesi baru muncul di bawah bagian scheduled pada sidebar, terpisah dari sesi manual mana pun yang sedang Anda buka. Bukalah untuk melihat apa yang dikerjakan Claude, meninjau perubahannya, atau menjawab permission prompt yang sedang ditunggunya. Claude bisa mengedit file, menjalankan perintah, membuat commit, dan membuka pull request, persis seperti pada sesi yang Anda mulai sendiri.

Satu kemampuan absen: tugas terjadwal tidak bisa mengirim maupun menerima pesan antarsesi desktop Anda lewat permukaan sesi aplikasinya. Kalau model mental Anda tentang otomasi melibatkan tugas yang saling berbicara, di situlah batasnya — koordinasinya harus lewat repository, atau lewat mekanisme di luar aplikasi desktop.

Permission, dan cara menghindari run yang mandek

Tiap tugas punya permission mode sendiri, disetel saat Anda membuat atau mengeditnya, dan allow rule dari user settings Anda ikut berlaku. Tugas dalam manual mode yang membutuhkan tool tanpa izin akan mandek sampai Anda menyetujuinya — sesinya tetap terbuka di sidebar, jadi tidak ada yang hilang, tetapi tidak ada pula yang terjadi sampai Anda menyadarinya.

• Klik run now segera setelah membuat sebuah tugas, awasi permission prompt-nya, dan pilih always allow untuk masing-masing.
• Run berikutnya lalu menyetujui otomatis tool yang sama tanpa bertanya, dan Anda bisa meninjau atau mencabut persetujuan itu dari halaman detail tugasnya.
• Dua kategori tidak pernah menawarkan always-allow: connector tool yang disetel organisasi Anda ke ask, dan tool MCP yang ditandai membutuhkan interaksi pengguna. Run yang memanggilnya mandek setiap kali.
• Riwayat run menampilkan run yang dilewati beserta alasannya — tertidur, run sebelumnya masih berjalan, atau terlalu banyak tugas lain yang sedang jalan — dan di situlah tempat memeriksa sebelum menyimpulkan sebuah tugas rusak.

Tugasnya di disk

Tiap tugas adalah sebuah file skill, dan itu membuat mengedit prompt-nya di editor jadi lurus sekaligus memperjelas apa yang termasuk di dalamnya dan tidak. Menghapus sebuah tugas mengarsipkan sesinya, dengan kotak centang di dialog konfirmasi untuk sekaligus menghapus filenya.

# The prompt lives on disk as a skill file:
~/.claude/scheduled-tasks/<task-name>/SKILL.md
#   (or under CLAUDE_CONFIG_DIR if you set it)
#
# YAML frontmatter for name and description, prompt as the body.
# Edits take effect on the NEXT run.

# What is NOT in that file, and must be changed through the
# Edit form or by asking Claude:
#   schedule
#   folder
#   model
#   enabled state

# A running task can also reschedule ITSELF, using the
# update_scheduled_task MCP tool — so a code review can move
# itself earlier when it notices a release branch appeared.

Memilih di antara ketiganya

Ketiga mekanismenya layak dimiliki, dan pilihannya ditentukan oleh satu pertanyaan masing-masing.

Satu pertanyaan per mekanisme:

Kebiasaan yang membuat semua ini andal bagi saya adalah menulis setiap prompt terjadwal seolah saya tidak tahu kapan ia akan berjalan, karena pada praktiknya memang tidak. Batasi pekerjaannya oleh apa yang bisa ia amati alih-alih oleh jam, nyalakan toggle worktree supaya sebuah run tidak bisa menyapu apa pun yang saya tinggalkan setengah jadi, dan setujui tool-nya sekali lewat run manual. Setelah itu ia benar-benar rendah perawatan, dan hanya otomasi semacam itulah yang layak dimiliki.