Feature Request: Option to separate Tasks from checklists

[littlelinuxoid]

This might be a very personalized issue, but in case it is not - i would like to be able to separate tasks from checklists that might not have anything to do with tasks per se.

For example, i have a rather huge checklist of literature in my vault which tracks the books i read/plan to read. It makes perfect sense for it to be a checklist, but the app treats every book in this note as a task, which pollutes the tasks menu.

I think, it would be better for tasks to have their own special notation e.g. @TASK(*task body*) or something like that. Markdown's check boxes have a lot of use cases and treating them as a task-only thing seems to be a bit wasteful. It makes sense for a ZenNotes-specific task feature to have a ZenNotes-specific notation that would separate tasks from everything else.

[naingyeminn]

I ran into the same issue. I have project documents containing embedded checklists, which completely flooded my Tasks view. As a temporary workaround, I had to move those project directories into separate vaults.

To give users better control, a few filtering options would be extremely helpful:

• Folder/Database Exclusion: An option to exclude specific folders or databases from Tasks entirely.
• Opt-in Tagging: An option to require a specific marker or tag (e.g., @TASK or #tasks/) on a checklist item for it to populate in the Tasks panel.

[yfernandes]

Yeah, same here. I have a catalog of Backlogged movies and shows to watch as well as project specific tasklists.

Maybe we could solve this in the front after of a note, instead of having to parse the actual notes body that could be massive and slow down indexing of the vault.

Maybe a "type: tasks" or "contain: tasks" and a sister prop "task-scope: "

[littlelinuxoid]

In addition, there is an extension Obsidian that adds tasks functionality. It solves this problem by marking individual checkboxes with #task:

• #task Hello, World!

Only these checkboxes are tracked by the tasks system. I think this is a perfect solution for the problem being discussed here.

[adibhanna]

Thanks for this thread. All three of you are describing the same real gap from different angles, and after digging through how task scanning actually works I agree something is missing. Laying out a concrete design here before building anything, so you can poke holes in it.

Where the pain actually comes from

Today one rule decides everything: every - [ ] line in a live note is a task, on every surface (Tasks view, calendars, the home widget, zn tasks, MCP). Two details make it worse than it sounds:

• A task with no due date lands in the Today group. So a big reading checklist doesn't just appear somewhere in Tasks, it lands in the most prominent bucket in the app.
• There is currently no escape hatch at all. Trash is the only folder the scanner skips (archived notes are still scanned), and the Tasks filter can't negate. Which is why @naingyeminn ended up splitting vaults: that really is the only thing that works today.

The plan: two mechanisms, both stored in your vault, defaults unchanged

An app setting would be the wrong home for this. ZenNotes scans tasks in several runtimes (desktop, the server that web and mobile talk to, the CLI, MCP), and a desktop-side toggle would make them disagree. Markers that live in the vault itself apply everywhere automatically.

1. Per-note opt-out: tasks: false in frontmatter. One line turns a note into a pure checklist: checkboxes still render and toggle in the editor exactly as before, the note just stops feeding Tasks, calendars, the CLI, and MCP. This is the reading-list / movie-backlog case (@littlelinuxoid, @yfernandes). On performance (@yfernandes): indexing already reads every note body for due: tokens and already parses frontmatter on every runtime, so the check costs nothing, and an excluded note actually makes the scan cheaper. Since it's plain frontmatter, Obsidian and other tools ignore it and vaults stay portable.

2. Folder exclusion, stored in the vault's own settings. A list of excluded folders in the vault settings file that already travels with your vault (it's where primaryNotesLocation lives), enforced at scan time in every runtime. Because a database is a folder on disk, this covers "exclude this database" too (@naingyeminn). You wouldn't hand-edit JSON: there'd be an "Exclude from Tasks" command / context-menu entry on a folder, plus a list in Settings.

What I'm deliberately not doing yet: the Obsidian-Tasks-style #task marker

I get the appeal of the per-line opt-in and the Tasks-plugin precedent. But as a default it would empty every existing user's Tasks view on upgrade, and as an always-on convention it makes every task line carry a tag. If demand persists after the two mechanisms above ship, it slots in cleanly later as a per-vault mode (something like tasksMode: all | tagged in the same vault settings), so nothing in this design blocks it.

Open questions for you three

• Key naming: tasks: false. Would you expect synonyms like tasks: off or tasks: exclude to work too?
• A note can also be a whole-note "file task" (frontmatter tags: [task], TaskNotes-style). I'd have tasks: false win and suppress that too. Any objection?
• I'd apply exclusions to every surface, including MCP and zn tasks: no partial visibility. Does anyone have a case where they'd want the Tasks view clean but the CLI or their AI assistant seeing everything?
• @littlelinuxoid: does the per-note opt-out cover your literature list in practice, or do you have notes where some checkboxes are tasks and some aren't, so only per-line granularity would do?

If the shape looks right, I'll start with the per-note opt-out.

[i-zhivetiev]

I’ve just started using ZenNotes, and the keyboard-first approach is an absolute killer feature for me. But I also ran into the task model, which I find a bit confusing.

A note can also be a whole-note "file task" (frontmatter tags: [task], TaskNotes-style). I'd have tasks: false win and suppress that too. Any objection?

I have a lot of notes that are small projects. In other words, a project is a task-note with checklists inside. It would be great to see these TaskNotes on the Kanban board, but not show the checklist contents on that same board.

[naingyeminn]

• Key naming: tasks: false. Would you expect synonyms like tasks: off or tasks: exclude to work too?

tasks: false or tasks: off would be enough for me.

• A note can also be a whole-note "file task" (frontmatter tags: [task], TaskNotes-style). I'd have tasks: false win and suppress that too. Any objection?

Perfect.

• I'd apply exclusions to every surface, including MCP and zn tasks: no partial visibility. Does anyone have a case where they'd want the Tasks view clean but the CLI or their AI assistant seeing everything?

Should apply to every surface, but adding an option like --all in CLI to show excluded tasks would be useful if we needed to list out everything.

[vlcinsky]

What about the other way around. Allow tasklist, kanban, calendar to be filtered. Per tag, tag query, file or folder.

[adibhanna]

This is built and lands in 2.23.0 (PR #548). What shipped, and the answers to the open questions above:

Per-note opt-out. tasks: false in frontmatter turns a note into a pure checklist: checkboxes render and toggle exactly as before, the note just stops feeding the Tasks list, the boards, the calendars, zn task list, and MCP. tasks: off works as a synonym (@naingyeminn), and it wins over a tags: [task] file task, as discussed.

@i-zhivetiev, your case got its own value. tasks: note keeps the note's own file task on the Kanban board while silencing its inline checkboxes, so a project note is one card instead of its whole checklist. Anything other than false / off / note means today's behavior, so nothing changes on upgrade.

Folder exclusion. The vault settings now carry an excluded-folders list: right-click a folder in the sidebar for "Exclude from Tasks", or manage the list under Settings → Tasks. Because a database is a folder on disk, this covers excluding a database too (@naingyeminn). The list is stored in the vault itself, so desktop, web, the self-hosted server, the CLI, MCP, and mobile all agree.

The CLI escape hatch (@naingyeminn): it exists, but the flag is --include-excluded rather than --all, because zn task list --all already means "every status". The MCP list_tasks tool takes includeExcluded: true, and the server API takes ?includeExcluded=1. The default everywhere stays fully excluded: no partial visibility. Toggling a task by its explicit id still works even when it is excluded, since an explicit id is an explicit ask.

Deferred, on purpose:

• The Obsidian-Tasks-style per-line #task opt-in (@littlelinuxoid): as a default it would empty every existing user's Tasks view on upgrade. The vault settings leave room for it later as a per-vault mode; if the per-note and per-folder switches don't cover your literature list in practice, say so here and it moves up the list.
• View-side filtering (@vlcinsky): filtering the Tasks list, board, and calendar by tag, query, or folder is a real feature of its own rather than a variant of this one. It deserves its own issue; happy to open one if you want to shape it.

Closing as done; it ships with 2.23.0.

[littlelinuxoid]

@adibhanna Sorry for the late reply. First off, yes, i think that a #task tag for per-checkbox control would be an amazing thing to be an opt-in functionality for backwards compatibility with existing vaults.

Regarding your questions.

1. I do not care about naming that much, but tasks: false seems the most intuitive to me personally.

2. No objections from me, i think it is good to have this kind of precedence. It also seems very convenient to just be able to "turn off" the file without changing the tags.

3. I cannot reason about MCP and CLI UX since i do not use neither AI nor the zn utility in my terminal. I will let others answer that properly.