---
read_when:
- زمانبندی کارهای پسزمینه یا بیدارباشها
- اتصال محرکهای خارجی (Webhookها، Gmail) به OpenClaw
- تصمیمگیری بین Heartbeat و Cron برای وظایف زمانبندیشده
sidebarTitle: Scheduled tasks
summary: کارهای زمانبندیشده، Webhookها و محرکهای Gmail PubSub برای زمانبند Gateway
title: وظایف زمانبندیشده
x-i18n:
generated_at: "2026-07-16T15:27:59Z"
model: gpt-5.6
postprocess_version: locale-links-v1
prompt_version: 32
provider: openai
source_hash: 9a419d4376fa08df1c429c167ead6918262cc34b986a85ffec024023f6da1eef
source_path: automation/cron-jobs.md
workflow: 16
---
Cron زمانبند داخلی Gateway است. کارها را بهصورت پایدار نگه میدارد، عامل را در زمان مناسب بیدار میکند و میتواند خروجی را به یک کانال گفتگو، یک Webhook یا هیچ مقصدی تحویل دهد.
## شروع سریع
```bash
openclaw cron create "2027-02-01T16:00:00Z" \
--name "Reminder" \
--session main \
--system-event "Reminder: پیشنویس مستندات cron را بررسی کنید" \
--wake now \
--delete-after-run
```
```bash
openclaw cron list
openclaw cron get
openclaw cron show
```
```bash
openclaw cron runs --id
```
## نحوه کار cron
- Cron **درون فرایند Gateway** اجرا میشود، نه درون مدل. برای فعالشدن زمانبندیها، Gateway باید در حال اجرا باشد.
- تعریف کارها، وضعیت زمان اجرا و تاریخچه اجرا در پایگاهداده وضعیت SQLite مشترک OpenClaw بهصورت پایدار نگهداری میشوند؛ بنابراین راهاندازیهای مجدد باعث ازدسترفتن زمانبندیها نمیشوند.
- هر اجرای cron یک رکورد [وظیفه پسزمینه](/fa/automation/tasks) ایجاد میکند.
- کارهای یکباره (`--at`) بهطور پیشفرض پس از موفقیت خودکار حذف میشوند؛ برای نگهداشتن آنها، `--keep-after-run` را ارسال کنید.
- بودجه زمانی واقعی هر اجرا: در صورت تنظیم، `--timeout-seconds`. در غیر این صورت، کارهای نوبت عاملِ ایزوله/جداشده با نگهبان 60 دقیقهای خود cron محدود میشوند، پیش از آنکه مهلت زمانی نوبت عامل زیربنایی (`agents.defaults.timeoutSeconds`، با مقدار پیشفرض 48 ساعت) اصلاً اعمال شود؛ مهلت پیشفرض کارهای فرمانی 10 دقیقه است.
- هنگام راهاندازی Gateway، کارهای نوبت عامل ایزولهای که موعدشان گذشته است، بهجای بازپخش فوری دوباره زمانبندی میشوند تا کارهای راهاندازی اولیه مدل/ابزار از بازه اتصال کانال خارج بمانند.
- اگر `openclaw agent` را از cron سیستم یا زمانبند خارجی دیگری اجرا میکنید، با وجود اینکه CLI از قبل `SIGTERM`/`SIGINT` را مدیریت میکند، آن را با سازوکار تشدیدِ خاتمه اجباری محصور کنید. اجراهای متکی به Gateway از Gateway میخواهند اجراهای پذیرفتهشده را لغو کند؛ اجراهای محلی و اجرای جایگزین تعبیهشده نیز همان سیگنال لغو را دریافت میکنند. برای `timeout` در GNU، `timeout -k 60 600 openclaw agent ...` را به `timeout 600 ...` ساده ترجیح دهید — مقدار `-k` در صورتی که فرایند نتواند بهموقع تخلیه شود، نقش پشتیبان نهایی را دارد. برای واحدهای systemd، پیش از خاتمه نهایی از سیگنال توقف `SIGTERM` همراه با یک بازه مهلت (`TimeoutStopSec`) استفاده کنید. استفاده مجدد از یک `--run-id` درحالیکه اجرای اصلی Gateway هنوز فعال است، مورد تکراری را بهجای آغاز اجرای دوم، در حال اجرا گزارش میکند.
- اجراهای ایزوله هنگام تکمیل، در حد بهترین تلاش زبانهها/فرایندهای مرورگر ردیابیشده برای نشست `cron:` خود را میبندند و هر نمونه زمان اجرای MCP همراهی را که برای کار ایجاد شده است، از طریق همان مسیر پاکسازی مشترک مورد استفاده اجراهای نشست اصلی و نشست سفارشی آزاد میکنند. خطاهای پاکسازی نادیده گرفته میشوند تا نتیجه cron همچنان نتیجه نهایی باشد.
- اجراهای ایزوله دارای مجوز محدود پاکسازی خودکار cron میتوانند وضعیت زمانبند، فهرستی پالایششده شامل فقط کار خودشان و تاریخچه اجرای همان کار را بخوانند و تنها مجاز به حذف کار خودشان هستند.
- اجراهای ایزوله از پاسخهای تأیید دریافت قدیمی محافظت میکنند: اگر نخستین نتیجه فقط یک بهروزرسانی وضعیت موقت (`on it`، `pulling everything together` و نشانههای مشابه) باشد و هیچ زیرعامل فرزندی همچنان مسئول پاسخ نهایی نباشد، OpenClaw پیش از تحویل یکبار دیگر برای دریافت نتیجه واقعی درخواست میکند.
- فراداده ساختیافته رد اجرا (از جمله پوششدهندههای `UNAVAILABLE` میزبان Node که خطای تودرتوی آنها با `SYSTEM_RUN_DENIED` یا `INVALID_REQUEST` آغاز میشود) شناسایی میشود تا فرمان مسدودشده بهعنوان اجرای موفق گزارش نشود؛ درعینحال، نثر عادی دستیار بهاشتباه رد اجرا تلقی نمیشود.
- شکستهای عامل در سطح اجرا حتی بدون بار پاسخ نیز خطای کار محسوب میشوند؛ بنابراین شکستهای مدل/ارائهدهنده شمارندههای خطا را افزایش میدهند و بهجای موفق اعلامکردن کار، اعلانهای شکست را فعال میکنند.
- وقتی یک کار به `timeoutSeconds` میرسد، cron اجرا را لغو میکند و یک بازه کوتاه برای پاکسازی به آن میدهد. اگر اجرا تخلیه نشود، پاکسازی تحت مالکیت Gateway پیش از ثبت اتمام مهلت توسط cron، مالکیت نشست آن اجرا را بهاجبار پاک میکند تا کار گفتگوی صفشده پشت یک نشست پردازش قدیمی گیر نکند.
- توقفهای مرحله تنظیم/راهاندازی مهلت زمانی مختص همان مرحله دریافت میکنند (برای مثال `cron: isolated agent setup timed out before runner start` یا `cron: isolated agent run stalled before execution start (last phase: context-engine)`). این نگهبانها ارائهدهندگان تعبیهشده و متکی به CLI را حتی پیش از آغاز فرایند CLI خارجی آنها پوشش میدهند و مستقل از مقادیر طولانی `timeoutSeconds` محدود میشوند تا شکستهای شروع سرد/احراز هویت/بافت بهسرعت آشکار شوند.
تطبیق وظیفه cron در درجه نخست تحت مالکیت زمان اجرا و در درجه دوم متکی به تاریخچه پایدار است: تا زمانی که زمان اجرای cron همچنان آن کار را در حال اجرا ردیابی کند، وظیفه فعال cron زنده میماند، حتی اگر یک ردیف نشست فرزند قدیمی همچنان وجود داشته باشد. پس از آنکه زمان اجرا دیگر مالک کار نباشد و بازه مهلت 5 دقیقهای پایان یابد، بررسیهای نگهداری گزارشهای اجرای پایدار و وضعیت کار را برای اجرای منطبق با `cron::` بررسی میکنند. وجود یک نتیجه پایانی در آنجا دفتر وظیفه را نهایی میکند؛ در غیر این صورت، نگهداری تحت مالکیت Gateway میتواند وظیفه را `lost` علامتگذاری کند. ممیزی آفلاین CLI میتواند با استفاده از تاریخچه پایدار بازیابی انجام دهد، اما خالیبودن مجموعه کارهای فعال درونفرایندی خودش، اثباتی بر پایانیافتن اجرای تحت مالکیت Gateway نیست.
## انواع زمانبندی
| نوع | پرچم CLI | توضیحات |
| --------- | ----------- | -------------------------------------------------------------------------------------------------------- |
| `at` | `--at` | برچسب زمانی یکباره (ISO 8601 یا نسبی مانند `20m`) |
| `every` | `--every` | بازه ثابت (`10m`، `1h`، `1d`) |
| `cron` | `--cron` | عبارت cron پنجفیلدی یا ششفیلدی با `--tz` اختیاری |
| `on-exit` | `--on-exit` | یکبار هنگام خروج فرمان تحت نظارت فعال میشود (محرک رویداد؛ پس از برچیدن نوبت باقی میماند؛ `--on-exit-cwd` اختیاری) |
برچسبهای زمانی بدون منطقه زمانی، UTC در نظر گرفته میشوند. برای تفسیر یک تاریخوزمان `--at` بدون اختلاف زمانی، یا ارزیابی یک عبارت cron در آن منطقه زمانی IANA، `--tz America/New_York` را اضافه کنید. عبارتهای cron بدون `--tz` از منطقه زمانی میزبان Gateway استفاده میکنند. `--tz` همراه با `--every` یا `--on-exit` معتبر نیست.
عبارتهای تکرارشونده ابتدای ساعت (دقیقه `0` با فیلد ساعت عام) برای کاهش جهشهای بار بهطور خودکار تا 5 دقیقه پخش میشوند. برای اجبار زمانبندی دقیق از `--exact`، یا برای تعیین یک بازه صریح از `--stagger 30s` استفاده کنید (فقط زمانبندیهای cron).
### روز ماه و روز هفته از منطق OR استفاده میکنند
عبارتهای cron توسط [croner](https://github.com/Hexagon/croner) تجزیه میشوند. وقتی فیلدهای روز ماه و روز هفته هر دو غیرعام باشند، croner در صورت تطابق **هرکدام** از فیلدها تطابق را اعلام میکند، نه فقط در صورت تطابق هر دو. این رفتار استاندارد cron از نوع Vixie است.
```bash
# منظور: «ساعت 9 صبح روز پانزدهم، فقط اگر دوشنبه باشد»
# واقعیت: «ساعت 9 صبح هر روز پانزدهم، و ساعت 9 صبح هر دوشنبه»
0 9 15 * 1
```
این عبارت بهجای 0-1 بار در ماه، تقریباً 5-6 بار در ماه فعال میشود. برای الزام هر دو شرط، از اصلاحگر روز هفته `+` در croner (`0 9 15 * +1`) استفاده کنید، یا بر اساس یکی از فیلدها زمانبندی کنید و دیگری را در درخواست یا فرمان کار خود بررسی کنید.
## محرکهای رویداد (ناظرهای شرط)
یک محرک رویداد، اسکریپت شرط بدون رابطی را به یک زمانبندی `every` یا `cron` اضافه میکند. Cron اسکریپت را در موعد کار ارزیابی میکند و فقط زمانی بار عادی را اجرا میکند که اسکریپت `fire: true` برگرداند:
```json5
{
schedule: { kind: "every", everyMs: 30000 },
trigger: {
// فقط زمانی فعال میشود که وضعیت مشاهدهشده با ارزیابی قبلی متفاوت باشد.
script: "const res = await tools.call('exec', { command: 'gh pr checks 123 --json state -q \\'.[].state\\' | sort -u' }); const status = String(res?.result?.details?.aggregated ?? '').trim(); json({ fire: status !== trigger.state?.status, message: `CI درخواست ادغام 123: ${trigger.state?.status ?? 'نامشخص'} -> ${status}`, state: { status } });",
once: false,
},
payload: { kind: "agentTurn", message: "تغییر وضعیت CI را بررسی کنید." },
}
```
اسکریپت باید `{ fire, message?, state? }` برگرداند. وضعیت JSON قبلی بهشکل `trigger.state` با انجماد عمیق در دسترس است؛ برای نگهداری پایدار آن، مقدار جدید `state` را برگردانید. وضعیت به 16 KB محدود است. وقتی نتیجه فعالسازی شامل `message` باشد، cron پیش از اجرا آن را به متن رویداد سیستم یا پیام نوبت عامل اضافه میکند. `once: true` پس از نخستین اجرای موفق بار فعالشده، کار را غیرفعال میکند.
`fire: false` وضعیت ارزیابی و شمارندهها را بهصورت پایدار نگه میدارد، سپس بدون ایجاد تاریخچه اجرا دوباره زمانبندی میکند. اگر اجرای بار فعالشده شکست بخورد، `state` برگشتی **بهصورت پایدار نگهداری نمیشود** — ارزیابی بعدی وضعیت قبلی را میبیند و میتواند دوباره فعال شود؛ بنابراین اسکریپتها را بهعنوان بررسیهای فقطخواندنی بنویسید و کنشها را در بار نگه دارید. زمانبندیهای محرک دارای حداقل بازه قابلتنظیم هستند (بهطور پیشفرض 30 ثانیه). هر ارزیابی بودجه زمانی واقعی 30 ثانیه و حداکثر 5 فراخوانی ابزار دارد.
فعالکردن `cron.triggers.enabled` به اسکریپتهای نوشتهشده توسط عامل اجازه میدهد بدون رابط و با **خطمشی کامل ابزار عامل مالک، از جمله `exec`** اجرا شوند. این را اجرای بدون نظارت کد با مجوزهای آن عامل در نظر بگیرید؛ مگر اینکه همه عاملهای مجاز به ایجاد کارهای cron به همین میزان مورد اعتماد باشند، آن را غیرفعال نگه دارید.
یک ناظر را از فایل اسکریپت محلی ایجاد کنید (`-` اسکریپت را از ورودی استاندارد میخواند):
```bash
openclaw cron add \
--name "PR CI watcher" \
--every 30s \
--trigger-script ./watch-pr-ci.js \
--message "به تغییر وضعیت CI پاسخ دهید" \
--session isolated
```
## بارها
هر کار دقیقاً یک نوع بار دارد که با پرچم انتخاب میشود:
| بار | پرچم | اجرا |
| ------------- | ---------------------------------------------- | ------------------------------------------------------- |
| رویداد سیستم | `--system-event ` | در نشست اصلی در صف قرار میگیرد و بهتنهایی مدل را فراخوانی نمیکند |
| پیام عامل | `--message ` | یک نوبت عامل متکی به مدل |
| فرمان | `--command ` یا `--command-argv ` | یک پوسته/فرایند روی میزبان Gateway، بدون فراخوانی مدل |
### گزینههای نوبت عامل
متن پرامپت (برای کارهای ایزوله/نشست فعلی/نشست سفارشی الزامی است).
بازنویسی مدل؛ باید به یک مدل مجاز نگاشت شود، در غیر این صورت اجرا با خطای اعتبارسنجی ناموفق میشود.
فهرست مدلهای جایگزین برای هر کار، برای مثال `--fallbacks openai/gpt-5.6-sol,openrouter/meta-llama/llama-3.3-70b-instruct:free`. برای اجرای سختگیرانه بدون مدل جایگزین، `--fallbacks ""` را وارد کنید.
در `cron edit`، بازنویسی مدل جایگزین مختص کار را حذف میکند تا کار از تقدم مدل جایگزین پیکربندیشده پیروی کند. نمیتوان آن را با `--fallbacks` ترکیب کرد.
در `cron edit`، بازنویسی مدل مختص کار را حذف میکند تا کار از تقدم عادی مدل Cron پیروی کند (بازنویسی ذخیرهشده نشست Cron و در غیر این صورت مدل عامل/پیشفرض). نمیتوان آن را با `--model` ترکیب کرد.
بازنویسی سطح تفکر (`off|minimal|low|medium|high|xhigh|adaptive|max|ultra`). سطوح دردسترس همچنان به مدل انتخابشده و زماناجرای عامل بستگی دارند.
در `cron edit`، بازنویسی تفکر مختص کار را حذف میکند. نمیتوان آن را با `--thinking` ترکیب کرد.
از تزریق فایل راهاندازی فضای کاری صرفنظر میکند.
ابزارهایی را که کار میتواند استفاده کند محدود میکند، برای مثال `--tools exec,read`.
`--model` مدل اصلی کار را تنظیم میکند؛ بازنویسی `/model` نشست را جایگزین نمیکند، بنابراین زنجیرههای مدل جایگزین پیکربندیشده همچنان روی آن اعمال میشوند. مدلی که قابل نگاشت یا مجاز نباشد، بهجای بازگشت بیسروصدا به مدل پیشفرض، اجرا را با خطای صریح اعتبارسنجی ناموفق میکند. اگر کاری دارای `--model` باشد اما فهرست مدل جایگزین صریح یا پیکربندیشدهای نداشته باشد، OpenClaw بهجای افزودن بیسروصدای مدل اصلی عامل بهعنوان هدف پنهان تلاش مجدد، یک بازنویسی خالی مدل جایگزین ارسال میکند.
تقدم انتخاب مدل برای کارهای ایزوله، از بالاترین اولویت:
1. بار محتوای مختص کار `model` (پیکربندی صریح؛ مدل غیرمجاز اجرا را ناموفق میکند)
2. بازنویسی مدل هوک Gmail (فقط وقتی اجرا از Gmail آمده و آن بازنویسی مجاز است)
3. بازنویسی ذخیرهشده مدل نشست Cron که کاربر انتخاب کرده است
4. انتخاب مدل عامل/پیشفرض
حالت سریع از انتخاب زنده نهاییشده پیروی میکند. اگر پیکربندی مدل انتخابشده دارای `params.fastMode` باشد، Cron ایزوله بهطور پیشفرض از آن استفاده میکند؛ بازنویسی ذخیرهشده نشست `fastMode` (و سپس `fastModeDefault` عامل) در هر دو جهت همچنان بر پیکربندی مدل مقدم است. حالت خودکار از آستانه `params.fastAutoOnSeconds` مدل استفاده میکند که مقدار پیشفرض آن 60 ثانیه است.
اگر اجرا به تحویل زنده تعویض مدل برسد، Cron با ارائهدهنده/مدل تعویضشده دوباره تلاش میکند و آن انتخاب (و هر نمایه احراز هویت جدید) را برای اجرای فعال ذخیره میکند. تلاشهای مجدد محدود هستند: پس از تلاش اولیه و 2 تلاش مجدد تعویض، Cron بهجای ورود به حلقه، اجرا را متوقف میکند.
پیش از آغاز اجرای ایزوله، OpenClaw دسترسپذیری نقطههای پایانی محلی پیکربندیشده برای ارائهدهندگان `api: "ollama"` و `api: "openai-completions"` را که `baseUrl` آنها بازگشتی، شبکه خصوصی یا `.local` است بررسی میکند. این پیشبررسی زنجیره مدل جایگزین پیکربندیشده کار را پیمایش میکند و تنها زمانی اجرا را `skipped` علامتگذاری میکند که همه گزینهها دسترسناپذیر باشند؛ `--fallbacks ""` این پیمایش را بهطور سختگیرانه فقط به مدل اصلی محدود میکند. نقطه پایانی ازکارافتاده، بهجای شروع فراخوانی مدل، اجرا را با وضعیت `skipped` و خطایی روشن ثبت میکند. نتیجه برای هر نقطه پایانی 5 دقیقه در حافظه نهان میماند (نه برای هر کار یا مدل)، بنابراین تعداد زیادی کار سررسیدشده که یک سرور محلی ازکارافتاده Ollama/vLLM/SGLang/LM Studio را بهاشتراک میگذارند، بهجای هجوم درخواستها تنها هزینه یک بررسی را دارند. اجراهایی که بهدلیل پیشبررسی رد میشوند، عقبنشینی خطای اجرا را افزایش نمیدهند؛ برای فعالسازی هشدارهای مکرر ردشدن، `failureAlert.includeSkipped` را تنظیم کنید.
### بارهای محتوای فرمان
بارهای محتوای فرمان، اسکریپتهای قطعی را در زمانبند Gateway بدون آغاز یک نوبت مبتنی بر مدل اجرا میکنند. آنها روی میزبان Gateway اجرا میشوند، stdout/stderr را ضبط میکنند، اجرا را در تاریخچه Cron ثبت میکنند و همان حالتهای تحویل `announce`، `webhook` و `none` کارهای نوبت عامل را دوباره بهکار میگیرند.
Cron فرمان یک سطح خودکارسازی مدیریتی اپراتور در Gateway است، نه یک فراخوانی `tools.exec` عامل. ایجاد، بهروزرسانی، حذف یا اجرای دستی کارهای Cron به `operator.admin` نیاز دارد؛ اجراهای زمانبندیشده فرمان بعداً بهعنوان همان خودکارسازی نوشتهشده توسط مدیر، درون فرایند Gateway اجرا میشوند. خطمشی اجرای عامل (`tools.exec.mode`، پرامپتهای تأیید، فهرستهای مجاز ابزار مختص عامل) ابزارهای اجرایی قابلمشاهده برای مدل را کنترل میکند، نه بارهای محتوای Cron فرمان را.
```bash
openclaw cron create "*/15 * * * *" \
--name "بررسی عمق صف" \
--command "scripts/check-queue.sh" \
--command-cwd "/srv/app" \
--announce \
--channel telegram \
--to "-1001234567890"
```
`--command ` مقدار `argv: ["sh", "-lc", ]` را ذخیره میکند. برای اجرای دقیق argv بدون تجزیه پوسته از `--command-argv '["node","scripts/report.mjs"]'` استفاده کنید. گزینههای اختیاری `--command-env KEY=VALUE` (قابل تکرار)، `--command-input`، `--timeout-seconds` (پیشفرض 10 دقیقه)، `--no-output-timeout-seconds` و `--output-max-bytes` محیط فرایند، stdin و حدود خروجی را کنترل میکنند.
متن تحویلی از خروجی فرایند استخراج میشود: stdout غیرخالی در اولویت است؛ اگر stdout خالی و stderr غیرخالی باشد، stderr تحویل داده میشود؛ اگر هر دو موجود باشند، Cron یک بلوک کوچک `stdout:` / `stderr:` ارسال میکند. کد خروج `0` اجرا را با وضعیت `ok` ثبت میکند؛ خروج غیرصفر، سیگنال، پایان مهلت یا پایان مهلت بدون خروجی، وضعیت `error` را ثبت میکند و میتواند هشدارهای شکست را فعال کند. فرمانی که فقط `NO_REPLY` را چاپ کند، از سرکوب عادی توکن سکوت Cron استفاده میکند و چیزی به گفتوگو ارسال نمیکند.
## سبکهای اجرا
| سبک | مقدار `--session` | محل اجرا | مناسب برای |
| --------------- | ------------------- | ------------------------ | ------------------------------- |
| نشست اصلی | `main` | مسیر اختصاصی بیدارباش Cron | یادآوریها، رویدادهای سیستم |
| ایزوله | `isolated` | `cron:` اختصاصی | گزارشها، کارهای پسزمینه |
| نشست فعلی | `current` | در زمان ایجاد مقید میشود | کارهای تکرارشونده آگاه از زمینه |
| نشست سفارشی | `session:custom-id` | نشست نامگذاریشده پایدار | گردشکارهایی که بر تاریخچه بنا میشوند |
کارهای **نشست اصلی** یک رویداد سیستم را در مسیر اجرای متعلق به Cron در صف میگذارند و در صورت نیاز Heartbeat را بیدار میکنند (`--wake now` یا `--wake next-heartbeat`). آنها میتوانند از آخرین زمینه تحویل نشست اصلی هدف برای پاسخها استفاده کنند، اما نوبتهای معمول Cron را به مسیر گفتوگوی انسانی اضافه نمیکنند و تازگی بازنشانی روزانه/بیکاری نشست هدف را تمدید نمیکنند. کارهای **ایزوله** یک نوبت اختصاصی عامل را با نشستی تازه اجرا میکنند. **نشستهای سفارشی** (`session:xxx`) زمینه را میان اجراها حفظ میکنند و گردشکارهایی مانند جلسههای هماهنگی روزانه را ممکن میسازند که بر خلاصههای پیشین بنا میشوند.
رویدادهای Cron نشست اصلی، یادآوریهای مستقل رویداد سیستم هستند. آنها دستور «Read HEARTBEAT.md» پرامپت پیشفرض Heartbeat را بهطور خودکار شامل نمیشوند؛ اگر یادآوری باید `HEARTBEAT.md` را بررسی کند، این موضوع را صریحاً در متن رویداد Cron بیان کنید.
برای هر اجرا یک شناسه رونوشت/نشست جدید ایجاد میشود. OpenClaw ترجیحات امن (تنظیمات تفکر/سریع/پرمطلب، برچسبها، بازنویسیهای صریح مدل/احراز هویت انتخابشده توسط کاربر) را منتقل میکند، اما زمینه پیرامونی مکالمه را از ردیف Cron قدیمی به ارث نمیبرد: مسیریابی کانال/گروه، خطمشی ارسال یا صف، ارتقای سطح دسترسی، مبدأ یا اتصال زماناجرای ACP. وقتی یک کار تکرارشونده باید عمداً بر همان زمینه مکالمه بنا شود، از `current` یا `session:` استفاده کنید.
وقتی اجراهای ایزوله Cron زیرعاملها را هماهنگ میکنند، تحویل، خروجی نهایی نواده را بر متن میانی قدیمی والد ترجیح میدهد. اگر نوادهها همچنان در حال اجرا باشند، OpenClaw بهجای اعلام آن، بهروزرسانی ناقص والد را سرکوب میکند.
برای مقصدهای اعلام متنی Discord، OpenClaw بهجای پخش دوباره متن جریانی/میانی و پاسخ نهایی، متن نهایی و معیار دستیار را یکبار ارسال میکند. رسانه و بارهای محتوای ساختیافته Discord همچنان جداگانه تحویل داده میشوند تا پیوستها و مؤلفهها حذف نشوند.
## تحویل و خروجی
| حالت | آنچه رخ میدهد |
| ---------- | ------------------------------------------------------------------- |
| `announce` | اگر عامل ارسال نکرد، متن نهایی را بهعنوان تحویل جایگزین به مقصد میفرستد |
| `webhook` | بار محتوای رویداد پایانیافته را با POST به یک URL ارسال میکند |
| `none` | بدون تحویل جایگزین اجراکننده |
برای تحویل کانال از `--announce --channel telegram --to "-1001234567890"` استفاده کنید. برای موضوعات انجمن Telegram از `-1001234567890:topic:123` استفاده کنید؛ OpenClaw همچنین شکل کوتاه `-1001234567890:123` متعلق به Telegram را میپذیرد. فراخوانهای مستقیم RPC/پیکربندی میتوانند `delivery.threadId` را بهصورت رشته یا عدد ارسال کنند. مقصدهای Slack/Discord/Mattermost از پیشوندهای صریح (`channel:`، `user:`) استفاده میکنند. شناسههای اتاق Matrix به بزرگی و کوچکی حروف حساس هستند؛ از شناسه دقیق اتاق یا قالب `room:!room:server` متعلق به Matrix استفاده کنید.
وقتی تحویل اعلام از `channel: "last"` استفاده میکند یا `channel` را حذف میکند، مقصدی با پیشوند ارائهدهنده مانند `telegram:123` میتواند پیش از آنکه Cron به تاریخچه نشست یا یک کانال پیکربندیشده واحد بازگردد، کانال را انتخاب کند. فقط پیشوندهایی که Plugin بارگذاریشده اعلام کرده است انتخابگر ارائهدهنده هستند. اگر `delivery.channel` صریح باشد، پیشوند مقصد باید همان ارائهدهنده را نام ببرد؛ ترکیب `channel: "whatsapp"` با `to: "telegram:123"` بهجای اجازهدادن به WhatsApp برای تفسیر شناسه Telegram بهعنوان شماره تلفن، رد میشود. پیشوندهای نوع مقصد و سرویس (`channel:`، `user:`، `imessage:`، `sms:`) نحو مقصد متعلق به کانال باقی میمانند، نه انتخابگر ارائهدهنده.
برای کارهای ایزوله، تحویل گفتوگو مشترک است: اگر مسیر گفتوگو دردسترس باشد، عامل حتی با `--no-deliver` میتواند از ابزار `message` استفاده کند. اگر عامل به مقصد پیکربندیشده/فعلی ارسال کند، OpenClaw از اعلام جایگزین صرفنظر میکند. در غیر این صورت، `announce`، `webhook` و `none` فقط کاری را کنترل میکنند که اجراکننده پس از نوبت عامل با پاسخ نهایی انجام میدهد.
وقتی یک عامل از یک گفتوگوی فعال یادآوری ایزولهای ایجاد میکند، OpenClaw مقصد زنده تحویل حفظشده را برای مسیر اعلام جایگزین ذخیره میکند. کلیدهای داخلی نشست ممکن است حروف کوچک باشند؛ وقتی زمینه گفتوگوی فعلی دردسترس است، مقصدهای تحویل ارائهدهنده از آن کلیدها بازسازی نمیشوند.
تحویل اعلام ضمنی از فهرستهای مجاز کانال پیکربندیشده برای اعتبارسنجی و مسیریابی مجدد مقصدهای منقضی استفاده میکند. تأییدهای فروشگاه جفتسازی پیام خصوصی، گیرندگان خودکارسازی جایگزین نیستند؛ وقتی یک کار زمانبندیشده باید پیشدستانه به یک پیام خصوصی ارسال کند، `delivery.to` را تنظیم یا ورودی `allowFrom` کانال را پیکربندی کنید.
### اعلانهای شکست
اعلانهای شکست از مسیر مقصد جداگانهای پیروی میکنند:
- `cron.failureDestination` یک پیشفرض سراسری برای اعلانهای شکست تنظیم میکند.
- `job.delivery.failureDestination` آن را برای هر کار لغو میکند.
- اگر هیچکدام تنظیم نشده باشند و کار از قبل از طریق `announce` تحویل داده شود، اعلانهای شکست به مقصد اصلی اعلان بازمیگردند.
- `delivery.failureDestination` فقط در کارهای `sessionTarget="isolated"` پشتیبانی میشود، مگر اینکه حالت تحویل اصلی `webhook` باشد.
- `failureAlert.includeSkipped: true` یک کار یا سیاست سراسری هشدار Cron را برای هشدارهای مکرر اجرای ردشده فعال میکند. اجراهای ردشده شمارنده متوالی جداگانهای دارند، بنابراین بر پسروی خطای اجرا تأثیر نمیگذارند.
- `openclaw cron edit` تنظیم هشدار برای هر کار را ارائه میکند: `--failure-alert`/`--no-failure-alert`، `--failure-alert-after `، `--failure-alert-channel`، `--failure-alert-to`، `--failure-alert-cooldown`، `--failure-alert-include-skipped`/`--failure-alert-exclude-skipped`، `--failure-alert-mode` و `--failure-alert-account-id`.
### زبان خروجی
کارهای Cron زبان پاسخ را از کانال، محلیسازی یا پیامهای قبلی استنباط نمیکنند. قاعده زبان را در پیام یا الگوی زمانبندیشده قرار دهید:
```bash
openclaw cron edit \
--message "بهروزرسانیها را خلاصه کن. به زبان چینی پاسخ بده؛ URLها، کد و نام محصولات را بدون تغییر نگه دار."
```
برای فایلهای الگو، دستور زبان را در پرامپت رندرشده نگه دارید و پیش از اجرای کار بررسی کنید که جاینگهدارهایی مانند `{{language}}` پر شده باشند. اگر خروجی زبانها را با هم ترکیب میکند، قاعده را صریح بیان کنید؛ برای مثال: «برای متن روایی از زبان چینی استفاده کن و اصطلاحات فنی را به انگلیسی نگه دار.»
## نمونههای CLI
```bash
openclaw cron add \
--name "بررسی تقویم" \
--at "20m" \
--session main \
--system-event "Heartbeat بعدی: تقویم را بررسی کن." \
--wake now
```
```bash
openclaw cron create "0 7 * * *" \
"بهروزرسانیهای شبانه را خلاصه کن." \
--name "خلاصه صبحگاهی" \
--tz "America/Los_Angeles" \
--session isolated \
--announce \
--channel slack \
--to "channel:C1234567890"
```
```bash
openclaw cron add \
--name "تحلیل عمیق" \
--cron "0 6 * * 1" \
--tz "America/Los_Angeles" \
--session isolated \
--message "تحلیل عمیق هفتگی از پیشرفت پروژه." \
--model "opus" \
--thinking high \
--announce
```
```bash
openclaw cron create "0 18 * * 1-5" \
"استقرارهای امروز را بهصورت JSON خلاصه کن." \
--name "خلاصه استقرار" \
--webhook "https://example.invalid/openclaw/cron"
```
```bash
openclaw cron create "*/15 * * * *" \
--name "کاوش عمق صف" \
--command "scripts/check-queue.sh" \
--command-cwd "/srv/app" \
--announce \
--channel telegram \
--to "-1001234567890"
```
## مدیریت کارها
```bash
# فهرست همه کارها
openclaw cron list
# دریافت یک کار ذخیرهشده بهصورت JSON
openclaw cron get
# نمایش یک کار، شامل مسیر تحویل حلشده
openclaw cron show
# فعال/غیرفعالکردن بدون حذف
openclaw cron enable
openclaw cron disable
# ویرایش یک کار
openclaw cron edit --message "پرامپت بهروزشده" --model "opus"
# اجرای اجباری یک کار در همین حالا
openclaw cron run
# اجرای اجباری یک کار در همین حالا و انتظار برای وضعیت نهایی آن
openclaw cron run --wait --wait-timeout 10m --poll-interval 2s
# اجرا فقط در صورت فرارسیدن موعد
openclaw cron run --due
# مشاهده تاریخچه اجرا
openclaw cron runs --id --limit 50
# مشاهده یک اجرای دقیق
openclaw cron runs --id --run-id
# حذف یک کار
openclaw cron remove
# انتخاب عامل (راهاندازیهای چندعاملی)
openclaw cron create "0 6 * * *" "صف عملیات را بررسی کن" --name "پایش عملیات" --session isolated --agent ops
openclaw cron edit --clear-agent
```
بایگانی یک نشست (از طریق رابط کاربری کنترل یا `sessions.patch { archived: true }` از فراخواننده مدیر اپراتور) همه کارهای فعال Cron متصل به آن نشست را غیرفعال میکند: نشست ایزوله `cron:` آن، یک مقصد `session:` یا یک مسیر تحویل/بیدارسازی `sessionKey`. بازیابی نشست آن کارها را دوباره فعال نمیکند؛ از `openclaw cron enable ` استفاده کنید. نشستهایی که یک کار متصل فعال دارند، در نوار کناری رابط کاربری کنترل نشان ساعت نمایش میدهند.
`openclaw cron run ` پس از قرار دادن اجرای دستی در صف بازمیگردد. برای هوکهای خاموشسازی، اسکریپتهای نگهداری یا دیگر خودکارسازیهایی که باید تا پایان اجرای در صف مسدود بمانند، از `--wait` استفاده کنید؛ این مورد `runId` بازگرداندهشده را پایش میکند (مهلت پیشفرض `10m`، فاصله پایش `2s`) و برای وضعیت `ok` با `0` خارج میشود و برای `error`، `skipped` یا پایان مهلت انتظار با مقداری غیرصفر خارج میشود.
ابزار `cron` عامل، خلاصههای فشرده کار (`id`، `name`، `enabled`، `nextRunAtMs`، `scheduleKind`، `lastRunStatus`) را از `cron(action: "list")` بازمیگرداند؛ برای دریافت تعریف کامل یک کار از `cron(action: "get", jobId: "...")` استفاده کنید. فراخوانندههای مستقیم Gateway میتوانند `compact: true` را به `cron.list` ارسال کنند؛ حذف آن پاسخ کامل را همراه با پیشنمایشهای تحویل حفظ میکند.
`openclaw cron create` نام مستعار `openclaw cron add` است. کارهای جدید میتوانند از یک زمانبندی مکانی (`"0 9 * * 1"`، `"every 1h"`، `"20m"` یا یک مُهر زمانی ISO) و سپس یک پرامپت مکانی عامل استفاده کنند. برای ارسال payload اجرای پایانیافته با POST به یک نقطه پایانی HTTP، از `--webhook ` در `cron add|create` یا `cron edit` استفاده کنید؛ تحویل Webhook را نمیتوان با پرچمهای تحویل چت (`--announce`، `--channel`، `--to`، `--thread-id`، `--account`) ترکیب کرد. در `cron edit`، `--clear-channel`، `--clear-to`، `--clear-thread-id` و `--clear-account`، آن فیلدهای مسیریابی بهصورت جداگانه حذف میشوند (هرکدام همراه با پرچم تنظیم متناظر خود رد میشوند) — برخلاف `--no-deliver` که فقط تحویل بازگشتی اجراکننده را غیرفعال میکند.
نکته لغو مدل:
- `openclaw cron add|edit --model ...` مدل انتخابشده کار را تغییر میدهد.
- اگر مدل مجاز باشد، همان ارائهدهنده/مدل دقیق به اجرای ایزوله عامل میرسد.
- اگر مجاز نباشد یا قابل حل نباشد، Cron اجرا را با یک خطای اعتبارسنجی صریح ناموفق میکند.
- وصلههای payload مربوط به `cron.update` در API میتوانند `model: null` را برای پاککردن لغو مدل ذخیرهشده کار تنظیم کنند.
- `openclaw cron edit --clear-model` آن لغو را از CLI پاک میکند (با اثری همانند وصله `model: null`) و نمیتوان آن را با `--model` ترکیب کرد.
- زنجیرههای بازگشتی پیکربندیشده همچنان اعمال میشوند، زیرا `--model` در Cron مدل اصلی کار است، نه لغو `/model` نشست.
- `openclaw cron add|edit --fallbacks ...` مقدار `fallbacks` در payload را تنظیم میکند و بازگشتهای پیکربندیشده را برای آن کار جایگزین میکند؛ `--fallbacks ""` بازگشت را غیرفعال و اجرا را سختگیرانه میکند. `openclaw cron edit --clear-fallbacks` لغو مختص کار را پاک میکند.
- یک `--model` ساده که فهرست بازگشت صریح یا پیکربندیشدهای ندارد، بهطور ضمنی به مدل اصلی عامل بهعنوان مقصد تلاش مجدد اضافی منتقل نمیشود.
## Webhookها
Gateway میتواند نقاط پایانی Webhook از نوع HTTP را برای محرکهای خارجی در دسترس قرار دهد. آن را در پیکربندی فعال کنید:
```json5
{
hooks: {
enabled: true,
token: "shared-secret",
path: "/hooks",
},
}
```
### احراز هویت
هر درخواست باید توکن هوک را از طریق هدر دربر داشته باشد:
- `Authorization: Bearer ` (توصیهشده)
- `x-openclaw-token: `
توکنهای رشته پرسوجو رد میشوند.
یک رویداد سیستمی را برای نشست اصلی در صف قرار دهید:
```bash
curl -X POST http://127.0.0.1:18789/hooks/wake \
-H 'Authorization: Bearer SECRET' \
-H 'Content-Type: application/json' \
-d '{"text":"ایمیل جدید دریافت شد","mode":"now"}'
```
توضیح رویداد.
`now` یا `next-heartbeat`.
یک نوبت ایزوله عامل را اجرا کنید:
```bash
curl -X POST http://127.0.0.1:18789/hooks/agent \
-H 'Authorization: Bearer SECRET' \
-H 'Content-Type: application/json' \
-d '{"message":"صندوق ورودی را خلاصه کن","name":"ایمیل","model":"openai/gpt-5.6-sol"}'
```
فیلدها: `message` (الزامی)، `name`، `agentId`، `sessionKey` (نیازمند `hooks.allowRequestSessionKey=true`)، `idempotencyKey`، `wakeMode`، `deliver`، `channel`، `to`، `model`، `thinking`، `timeoutSeconds`.
نامهای سفارشی هوک از طریق `hooks.mappings` در پیکربندی حل میشوند. نگاشتها میتوانند payloadهای دلخواه را با الگوها یا تبدیلهای کد به کنشهای `wake` یا `agent` تبدیل کنند.
نقاط پایانی هوک را پشت loopback، tailnet یا یک پراکسی معکوس قابل اعتماد نگه دارید.
- از یک توکن اختصاصی هوک استفاده کنید؛ توکنهای احراز هویت Gateway را دوباره استفاده نکنید.
- `hooks.path` را در یک زیرمسیر اختصاصی نگه دارید؛ `/` رد میشود.
- `hooks.allowedAgentIds` را تنظیم کنید تا عامل مؤثری که هوک میتواند هدف بگیرد محدود شود؛ این شامل عامل پیشفرض هنگام حذف `agentId` نیز میشود.
- `hooks.allowRequestSessionKey=false` را حفظ کنید، مگر اینکه به نشستهای انتخابشده توسط فراخواننده نیاز داشته باشید.
- اگر `hooks.allowRequestSessionKey` را فعال میکنید، `hooks.allowedSessionKeyPrefixes` را نیز تنظیم کنید تا شکلهای مجاز کلید نشست محدود شوند.
- payloadهای هوک بهطور پیشفرض با مرزهای ایمنی محصور میشوند.
## یکپارچهسازی Gmail PubSub
محرکهای صندوق ورودی Gmail را از طریق Google PubSub به OpenClaw متصل کنید.
**پیشنیازها:** CLI مربوط به `gcloud`، `gog` (gogcli)، هوکهای فعال OpenClaw و Tailscale برای نقطه پایانی عمومی HTTPS.
### راهاندازی با جادوگر (توصیهشده)
```bash
openclaw webhooks gmail setup --account openclaw@gmail.com
```
این فرمان پیکربندی `hooks.gmail` را مینویسد، پیشتنظیم Gmail را فعال میکند و برای نقطه پایانی ارسال، Tailscale Funnel را بهصورت پیشفرض تنظیم میکند (`--tailscale funnel|serve|off`).
نشست مجزای هر پیام در پیشتنظیم Gmail، زمینه مکالمه را جدا میکند؛ اما ابزارها یا فضای کاری عامل مقصد را محدود نمیکند. بدون نگاشت سفارشی که `agentId` را تنظیم کند، هوکهای Gmail بهعنوان عامل پیشفرض اجرا میشوند.
برای صندوقهای ورودی نامطمئن، هوک را به یک عامل خواننده اختصاصی هدایت کنید، به آن عامل دسترسی فقطخواندنی یا بدون دسترسی به فضای کاری بدهید و نوشتن در سیستم فایل، پوسته، مرورگر و دیگر ابزارهای غیرضروری را منع کنید. اگر لازم است عامل اصلی را مطلع کند، فقط واگذاری لازم میان عاملها را مجاز کنید. به [تزریق پرامپت](/fa/gateway/security#prompt-injection)، [سندباکس و ابزارهای چندعاملی](/fa/tools/multi-agent-sandbox-tools) و [`tools.agentToAgent`](/fa/gateway/config-tools#toolsagenttoagent) مراجعه کنید.
### شروع خودکار Gateway
هنگامی که `hooks.enabled=true` فعال و `hooks.gmail.account` تنظیم شده باشد، Gateway هنگام راهاندازی `gog gmail watch serve` را آغاز میکند و پایش را بهطور خودکار تمدید میکند. برای انصراف، `OPENCLAW_SKIP_GMAIL_WATCHER=1` را تنظیم کنید.
### راهاندازی دستی یکباره
پروژه GCP مالک کلاینت OAuth مورد استفاده `gog` را انتخاب کنید:
```bash
gcloud auth login
gcloud config set project
gcloud services enable gmail.googleapis.com pubsub.googleapis.com
```
```bash
gcloud pubsub topics create gog-gmail-watch
gcloud pubsub topics add-iam-policy-binding gog-gmail-watch \
--member=serviceAccount:gmail-api-push@system.gserviceaccount.com \
--role=roles/pubsub.publisher
```
```bash
gog gmail watch start \
--account openclaw@gmail.com \
--label INBOX \
--topic projects//topics/gog-gmail-watch
```
### بازنویسی مدل Gmail
```json5
{
hooks: {
gmail: {
model: "openai/gpt-5.6-sol",
thinking: "high",
},
},
}
```
برای صندوقهای ورودی غیرقابلاعتماد، از جدیدترین نسل و بهترین سطح مدل موجود نزد ارائهدهندهٔ خود استفاده کنید. مقدار بالا یک نمونه است؛ مدل باید در کاتالوگ و فهرست مجاز پیکربندیشدهٔ شما وجود داشته باشد.
## پیکربندی
```json5
{
cron: {
enabled: true,
store: "~/.openclaw/cron/jobs.json",
maxConcurrentRuns: 8,
triggers: {
enabled: false,
minIntervalMs: 30000,
},
retry: {
maxAttempts: 3,
backoffMs: [30000, 60000, 300000],
retryOn: ["rate_limit", "overloaded", "network", "timeout", "server_error"],
},
webhookToken: "replace-with-dedicated-webhook-token",
sessionRetention: "24h",
},
}
```
مقادیر `retry` بالا، پیشفرضها هستند: حداکثر 3 تلاش مجدد با عقبنشینی `30s/60s/5m` و تلاش مجدد برای هر پنج دستهٔ گذرا. `webhookToken` در درخواستهای POST مربوط به Webhook کرون، بهصورت `Authorization: Bearer ` ارسال میشود.
`maxConcurrentRuns` هم ارسال زمانبندیشدهٔ کرون و هم اجرای نوبت عاملِ ایزوله را محدود میکند و مقدار پیشفرض آن 8 است. نوبتهای عاملِ ایزولهٔ کرون در داخل از مسیر اجرای اختصاصی `cron-nested` صف استفاده میکنند؛ بنابراین افزایش این مقدار اجازه میدهد اجراهای مستقل LLM کرون، بهجای اینکه فقط پوستههای بیرونی کرون آنها آغاز شوند، بهصورت موازی پیش بروند. مسیر مشترک غیرکرون `nested` با این تنظیم گستردهتر نمیشود.
`cron.store` یک کلید منطقی ذخیرهسازی و مسیر مهاجرت doctor است، نه یک فایل JSON زنده برای ویرایش دستی. دادههای کار در SQLite قرار دارند؛ برای اعمال تغییرات از CLI یا API مربوط به Gateway استفاده کنید.
غیرفعالکردن کرون: `cron.enabled: false` یا `OPENCLAW_SKIP_CRON=1`.
**تلاش مجدد تکاجرا**: خطاهای گذرا (محدودیت نرخ، بار بیشازحد، شبکه، پایان مهلت، خطای سرور) با استفاده از `retry.backoffMs` (پیشفرض: 30s، 60s، 5m)، حداکثر `retry.maxAttempts` بار (پیشفرض: 3) دوباره امتحان میشوند. خطاهای دائمی، کار را بلافاصله غیرفعال میکنند.
**تلاش مجدد دورهای**: خطاهای اجرای متوالی طبق یک زمانبندی طولانیتر عقبنشینی میکنند (30s، 60s، 5m، 15m، 60m). عقبنشینی پس از اجرای موفق بعدی بازنشانی میشود.
`cron.sessionRetention` (پیشفرض `24h`؛ `false` آن را غیرفعال میکند) ورودیهای نشست اجرای ایزوله را پاکسازی میکند. تاریخچهٔ اجرا، جدیدترین 2000 ردیف پایانی هر کار را نگه میدارد؛ ردیفهای گمشده بازهٔ پاکسازی 24 ساعتهٔ خود را حفظ میکنند.
هنگام ارتقا، `openclaw doctor --fix` را اجرا کنید تا فایلهای قدیمی `~/.openclaw/cron/jobs.json`، `jobs-state.json` و `runs/*.jsonl` به SQLite وارد شوند و با پسوند `.migrated` تغییر نام یابند. ردیفهای کارِ بدشکل در زمان اجرا نادیده گرفته میشوند و برای تعمیر یا بازبینی بعدی در `jobs-quarantine.json` کپی میشوند.
## عیبیابی
### نردبان فرمانها
```bash
openclaw status
openclaw gateway status
openclaw cron status
openclaw cron list
openclaw cron runs --id --limit 20
openclaw system heartbeat last
openclaw logs --follow
openclaw doctor
```
- `cron.enabled` و متغیر محیطی `OPENCLAW_SKIP_CRON` را بررسی کنید.
- تأیید کنید که Gateway بهطور پیوسته در حال اجرا است.
- برای زمانبندیهای `cron`، منطقهٔ زمانی (`--tz`) را در مقایسه با منطقهٔ زمانی میزبان بررسی کنید.
- وجود `reason: not-due` در خروجی اجرا به این معناست که اجرای دستی با `openclaw cron run --due` بررسی شده و هنوز زمان اجرای کار نرسیده بود.
- حالت تحویل `none` یعنی انتظار نمیرود ارسال جایگزینی از سوی اجراکننده انجام شود. عامل همچنان میتواند در صورت وجود مسیر گفتگو، مستقیماً با ابزار `message` ارسال کند.
- نبودن یا نامعتبر بودن مقصد تحویل (`channel`/`to`) یعنی ارسال خروجی نادیده گرفته شده است.
- در Matrix، کارهای کپیشده یا قدیمی با شناسههای اتاق `delivery.to` که با حروف کوچک نوشته شدهاند ممکن است شکست بخورند، زیرا شناسههای اتاق Matrix به بزرگی و کوچکی حروف حساساند. کار را با مقدار دقیق `!room:server` یا `room:!room:server` از Matrix ویرایش کنید.
- خطاهای احراز هویت کانال (`unauthorized`، `Forbidden`) به این معناست که تحویل بهدلیل اعتبارنامهها مسدود شده است.
- اگر اجرای ایزوله فقط توکن سکوت (`NO_REPLY` / `no_reply`) را برگرداند، OpenClaw تحویل مستقیم خروجی و مسیر جایگزین خلاصهٔ صفشده را سرکوب میکند؛ بنابراین چیزی به گفتگو ارسال نمیشود.
- اگر قرار است عامل خودش به کاربر پیام بدهد، بررسی کنید که کار یک مسیر قابلاستفاده داشته باشد (`channel: "last"` همراه با یک گفتگوی قبلی، یا یک کانال/مقصد صریح).
- تازگی بازنشانی روزانه و هنگام بیکاری بر مبنای `updatedAt` نیست؛ [مدیریت نشست](/fa/concepts/session#session-lifecycle) را ببینید.
- بیدارسازیهای کرون، اجراهای Heartbeat، اعلانهای exec و ثبت امور Gateway ممکن است ردیف نشست را برای مسیریابی/وضعیت بهروزرسانی کنند، اما `sessionStartedAt` یا `lastInteractionAt` را تمدید نمیکنند.
- برای ردیفهای قدیمی که پیش از وجود این فیلدها ایجاد شدهاند، اگر فایل همچنان در دسترس باشد، OpenClaw میتواند `sessionStartedAt` را از سربرگ نشستِ رونوشت JSONL بازیابی کند. ردیفهای بیکار قدیمی بدون `lastInteractionAt` از آن زمان شروع بازیابیشده بهعنوان خط مبنای بیکاری خود استفاده میکنند.
- کرون بدون `--tz` از منطقهٔ زمانی میزبان Gateway استفاده میکند.
- زمانبندیهای `at` بدون منطقهٔ زمانی، UTC در نظر گرفته میشوند.
- `activeHours` مربوط به Heartbeat از تفکیک منطقهٔ زمانی پیکربندیشده استفاده میکند.
## مرتبط
- [خودکارسازی](/fa/automation) — همهٔ سازوکارهای خودکارسازی در یک نگاه
- [وظایف پسزمینه](/fa/automation/tasks) — دفتر ثبت وظایف برای اجراهای کرون
- [Heartbeat](/fa/gateway/heartbeat) — نوبتهای دورهای نشست اصلی
- [منطقهٔ زمانی](/fa/concepts/timezone) — پیکربندی منطقهٔ زمانی