Claude/Desktop/Scheduled Task/Q/Is there a way to define a Claude Desktop scheduled task inside a repository's .claude directory so it's scoped to that repo and runs by default on any computer opening it?

• Is there a way to define a Claude/Desktop/Scheduled Task inside a repository's .claude directory so it's scoped to that repo and runs by default on any computer opening it?

  • AI Answer

    • Short answer: No. Scheduled-task registration is per-machine, home-directory state — there's no supported way to commit a task definition into a repo's .claude/ directory and have Desktop auto-register or auto-run it there on every machine.
    • Answer/Official from Schedule recurring tasks in Claude Code Desktop:
    • A scheduled task's editable prompt file lives at ~/.claude/scheduled-tasks/<task-name>/SKILL.md (or under CLAUDE_CONFIG_DIR if that's set) — always a home-directory path, never something read out of the project's own .claude/ folder.
    • Even that file is only part of the task: "Schedule, folder, model, and enabled state are not in this file: change them through the Edit form or ask Claude." Those fields live in Desktop's own local app state, tied to the machine that created the task — editing SKILL.md by hand changes only the name, description, and prompt body.
    • Creating a task also requires trusting a working folder through Desktop's UI (or a natural-language request in a session) — there's no config format that says "if a repo has this file in .claude/, register a task pointed at it."
    • Net effect: a scheduled task's identity (name, folder, schedule, model, permission mode) is registration state private to one Desktop installation. Nothing about it is discovered from repo contents, so opening the same repo on a second computer doesn't cause its scheduled tasks to reappear — each machine needs its own New routine → Local setup (UI or natural-language) pointed at that folder.
    • Closest available workaround: keep the prompt content itself in the repo — e.g. as a .claude/skills/<name>/SKILL.md or a plain instructions file — and make each machine's task Instructions field just reference it (e.g. "follow the workflow in .claude/skills/daily-review/SKILL.md"). That keeps the task's behavior version-controlled and consistent across machines, but the task's existence, folder binding, and schedule still have to be created once per machine through Desktop.

  • Symlink workflow

    • Where a session has the scheduled-tasks MCP tools available, Claude/Desktop/Scheduled Task/Q/Is there a declarative, programmatic way to manage Claude Desktop scheduled tasks that's scoped to a specific repo? covers a cleaner, officially-supported alternative to the symlink approach below.
    • A symlink can go further than the reference-workaround above: instead of the Instructions field merely pointing at a repo file, ~/.claude/scheduled-tasks/<task-name>/SKILL.md itself becomes a symlink into the repo, so editing the repo file changes the live task with no copy step.
    • 1. Commit the canonical prompt in the repo, e.g. .claude/scheduled-tasks/<task-name>/SKILL.md.
    • 2. On each machine, create the task once through Desktop's normal New routine → Local flow — this step is unavoidable, since schedule, folder, model, and enabled state are local app state, not file content.
    • 3. Delete the real SKILL.md Desktop just wrote and replace it with a symlink to the repo copy: ln -sf ~/ghq/<host>/<org>/<repo>/.claude/scheduled-tasks/<task-name>/SKILL.md ~/.claude/scheduled-tasks/<task-name>/SKILL.md.
    • Because ghq clones every repo to the same deterministic path on any machine (~/ghq/<host>/<org>/<repo>), that target path is stable — but the symlink itself must be absolute, since the home-directory end sits entirely outside the repo tree.
    • 4. Repeat step 2–3 on each additional machine that runs the task. After that, the prompt body, name, and description stay in lockstep across machines automatically; only the schedule/folder/model/enabled fields remain per-machine and still need manual updates through the Edit form if they change.
    • Risk to check before relying on this: if Desktop's Edit form ever saves SKILL.md by rewriting the file in place rather than only patching prompt text, that write could replace the symlink with a fresh real file and silently break the link.