Journals

Features

• Journal notes and calendar views can now list your tasks. A journal-tasks code block, placed in a journal note, lists that period's checkbox tasks — the note's own, its notelets', or both, depending on source — rolling up into every day's tasks on a month note, and so on, when you ask it to with depth: rollup. A new Tasks view block does the same inside a view, for a window around the view's selected date across the journals in its shelf, instead of one note's own period. Both default to what is still open — to-do, in progress or on hold — and filter further by status, heading or tag — a tag matching as Obsidian's tag search does, ignoring case and taking in the tags nested under it; every journal also gets its own Listing filter, under its settings page's Tasks section, which a fence or the view block's own filter overrides one condition type at a time rather than narrowing — except for the open-tasks default itself, which gives way instead, so a journal whose own filter names a status reaches a fence, or a view block, that named none. Each row renders its line as written — only the indentation or callout marker that placed it in the note is dropped, because the listing lays those out itself — so a theme's own styling for a marker such as [/] looks the same in the listing as it does in the note, and a checkbox nested under another stays nested; if a filter excludes the parent, it still shows above its matching child, dimmed and unclickable, so the child does not lose the line that gives it meaning. Sort by document order (the default, which reads note by note), by status, or by a due, scheduled, start, done or created date, which instead reorders the whole listing regardless of which note a task came from. Clicking a row's checkbox ticks it, writing your status map's marker for Done at that one position and changing nothing else on the line. A recurring line — one carrying 🔁 anywhere on it — is the one case that refuses: the Tasks plugin owns recurrence, and only its own toggle creates the next instance, so such a line is ticked through Tasks when it is installed and left alone, with a notice, when it is not. Two things worth knowing if you use Tasks alongside your own status map: its toggle always writes its own x on the recurring line it completes, whatever your map says elsewhere, and a line only has to mention 🔁 — not carry a real recurrence rule — to count as recurring. See Tasks in the manual.
• A decoration can now ask about tasks the way a task listing does. The new Check tasks condition reads as one sentence: Any, All or None of the tasks, with the status As in listing, Open, Done or All, looking in the note, its notelets, or both. As in listing follows whatever status the journal's own listing filter names, so a dot and that day's listing agree. All needs at least one task, and None needs a note, a notelet or a dated task note, so empty dates are never lit. Narrow further counts only tasks under a heading or carrying a tag. A decoration can hold more than one. See Decorations in the manual.
• The plugin API can now find the note before or after a date. previousNote(selector, date) and nextNote(selector, date) return the nearest note that exists on either side of the period holding the date, skipping periods with no note — so previousNote("Work Daily", "today") is the last day you wrote, not necessarily yesterday, which a rollover-style plugin previously had to answer by walking every markdown file in the vault. The period holding the date never counts as its own neighbor, each matched journal answers at most one note, and a journal with nothing on that side answers none. The Local REST API gains the same lookup as GET /journals/<name>/notes/<date>/previous and …/next, answering { "note": null } rather than a 404 when there is nothing there, and MCP agents get a journal_note_adjacent tool. apiVersion stays 1; a test double written as implements JournalsApi will stop compiling until it gains the two methods. The typed surface ships as [email protected].
• The plugin API can now list a period's tasks. tasksFor(selector, date, options) answers exactly what a journal-tasks code block in that period's note would list — your status map, the journal's own listing filter and the same open-tasks default — so another plugin's answer and your calendar agree about the same day, where one parsing the checkboxes itself cannot know what [/] means in your vault. It takes the code block's source, depth and status keys, with depth: rollup reaching the journal's shelf just as the code block does, and returns each matching task once, with its note, its 0-based line, its text as written, its status, any dates it carries and the line of the task it is nested under. Leaving status out lets the journal's own status condition apply; passing it, even as open, replaces it. A task the journal's listing filter hides — one outside its ## Tasks heading, say — is not returned. The Local REST API gains GET /journals/<name>/tasks/<date>, and MCP agents a journal_tasks tool. apiVersion stays 1. The typed surface ships as [email protected].
• Plugin API note and notelet events now say why they fired. noteAdded has always meant "entered the index", not "was created" — it fires once for every existing note at startup, again when a note is renamed or a tracked property changes, and for sync-conflict copies — so a plugin that wrote into notes from it could write into years of history. Each add and remove event now carries a reason: indexed for notes a vault walk finds, created for a note Journals itself just created on this device, appeared for one that arrived any other way, including by sync, and changed, moved, deleted or unindexed for the rest. noteAdded also carries canonical, false for a copy sharing its date with the note that owns it. Because created fires only on the device that created the note, a plugin that writes only on it writes once however many devices sync the vault. The plugin API documentation gains an Events section covering every reason and how to write safely from a handler. apiVersion stays 1. The typed surface ships as [email protected].
• Tasks kept one per note — the way TaskNotes keeps them, tagged #task with scheduled and due properties, or a hand-rolled due: convention — can now be listed and decorated. Turn on the new Task notes row in the Tasks section of the main settings page (it is off by default, and nothing changes for anyone who leaves it off); its gear icon sets how a task note is identified (a tag in its properties, or a property with or without a value), which folders and archive tag leave a note out, which property holds each date, the status property and what each of its values means, and the title, modified and recurrence properties — all starting from TaskNotes' own names. A task note lives in no period note, so it is placed by its date instead: by default on every day its scheduled or due date falls on, and in that week and month too. A journal-tasks code block, a Tasks view block and a Check tasks decoration each list or count task notes alongside checkbox tasks, and each can name a single date instead — the code block's date: key, the view block's and the decoration's Task date. So a dot can now light a day with no note at all, and None counts a dated task note the journal shows as something to look in. A Tag condition matches a task note's own tags in its properties and a Heading condition does not apply to one; a journal's own listing filter reaches task notes through its Status condition only. Clicking a task note's checkbox writes its status property, today's date into the completion date and the current time into the modified date when those are mapped; a recurring task note — one with a recurrence property set — appears on its stored dates only and refuses to tick, with a notice, since its series belongs to the plugin that manages it. Each journal chooses which task notes it shows, through a new Task notes row in its settings page's Tasks section: All, the default and what every journal does until you change it; None; or Matching, by tag (nested tags match, so #work also admits #work/project), by folder, or by a property equal to a value — link-aware, so a projects: ["[[Website]]"] note matches the value Website — with the conditions combined by all or any. It only narrows: a note that is not a task note never reaches a journal. A code block asks the journal of the note it sits in, a Tasks view block shows a task note when any journal it lists shows it, a decoration's dot asks its cell's journal, and a None dot counts only the task notes that journal shows, so a Work and a Personal daily journal no longer both list every task due that day. While TaskNotes is on and Task notes has never been turned on, the main settings page offers to set it up from TaskNotes: Set up… copies TaskNotes' identification (its task tag, or its task property and value), excluded folders, archive tag, property names and custom statuses — each completed status read as done, in-progress as in progress, the rest as to-do, with TaskNotes' default status written back for to-do — turns Task notes on and opens its settings to review the copy, which cancelling keeps. The copy is made once and does not follow later changes in TaskNotes; Don't show again hides the offer, and it never returns once Task notes has been on, nor appears when TaskNotes' settings cannot be read. The plugin API's tasksFor gains a date option, rejecting a value outside its choices with the new invalid-option error code, and the Local REST API route and MCP tool a matching taskDate parameter; a task note comes back with relations containing date, the first selected journal that shows it and that journal's period, and no line. apiVersion stays 1. See Task notes in the manual.
• Checkbox task lines that carry a date now appear by that date from anywhere in your vault, not only from the notes a journal owns. A line such as - [ ] Ship it 📅 2026-10-30 in a project note shows in that day's journal-tasks listing and tasks view block, lights the Check tasks decoration condition, and is returned by the plugin API, REST API and MCP tools. Both Tasks emoji (📅 ⏳ 🛫 ✅ ➕) and Dataview inline fields ([due:: …], (scheduled:: …), with the keys due, scheduled, start, created and completion) are read, and only a task's own line, never its subtasks. There is nothing to turn on: the vault is read once at startup, whenever Checkbox tasks is enabled, and notes under Obsidian's Excluded files are skipped unless a journal owns them. A change to Excluded files takes effect at the next restart or the next checkbox tasks settings change. If you upgrade, expect new items at once: dated lines from project notes, and dated lines from one journal's notes in other journals' listings and cells. Plugin API, REST and MCP clients see one change to existing output: relations lists every way a task can be placed, so a dated checkbox line in a period's own note now comes back as ["containment", "date"] where it read ["containment"], and when several journals are asked at once such a line is still attributed to the journal whose note holds it. Each journal's settings page carries a Dated tasks setting (under Tasks, in the Checkbox tasks modal) to choose which of these lines it shows: All (the default), Matching by tag, folder or property, or None. Matching works as it does for Task notes: by tag (nested tags match, so #work also admits #work/project), by folder, or by a property equal to a value (link-aware), with the conditions combined by all or any. It only narrows what arrives by date; checkboxes always show in the period note that holds them. It is asked per surface, as Task notes is: a journal-tasks block asks its note's journal, a tasks view block shows a line when any journal it lists does, and a decoration asks its cell's journal. See Tasks in the manual.
• Unfinished tasks can now be rolled forward into today's note. Roll over unfinished tasks, in the command palette, runs for the open note's journal — or asks which journal when no journal note is open — and takes the open checkbox tasks from that journal's last existing note, however long ago it was written, into the note for the period containing today, creating it if needed. Only lines inside the journal's Listing filter headings and tags roll, so a template's ## Habits list stays put, but its status conditions do not apply: only to-do, in-progress and on-hold tasks ever roll. A task brings everything nested under it, and an open task under a parent that stays behind arrives with that parent, so it keeps its meaning. Each task lands under the heading of the same name in today's note when the listing filter names that heading, otherwise under the journal's Target heading, otherwise at the end. By default the command copies and marks each original with a #rolled tag, which reads as the Rolled over status, as do the tasks nested under it — out of open listings and the calendar's open-task dots, never taken by the next roll, and excludable from your own Dataview, Tasks or search queries; a block id stays on the original, so links keep pointing at it. A journal can instead move the lines out of the earlier note, read its notelets too, or look back over more than one note, through a new Roll over row in its settings page's Tasks section; the marker and the copy-or-move and mark-as-rolled defaults live in Checkbox tasks' settings. A stored marker that is not a tag is kept as it was rather than replaced by #rolled, which would read every line it stamped as unfinished, and every roll and task move refuses, with a notice, until you enter a new one there. Task notes are never rolled, and the notice counts the ones left behind; it also says when the filter names a heading the earlier note lacks, and when an earlier note could not be marked, so its tasks would roll again. A note open in an editor, in any window, is edited there, so its unsaved typing is kept, and today's note is saved before an earlier one is marked or has its lines removed; an earlier note holding unsaved typing is left alone until it is saved, and the notice says so. If you upgrade, lines already tagged #rolled, and the tasks nested under them, read as Rolled over at once, leaving open listings and the calendar's open-task dots; change the marker in Checkbox tasks' settings if #rolled already means something else in your vault. See Rolling tasks forward in the manual.
• A single task can now be sent to another period's note. Put the cursor on a task and run Move task to the containing period to send it up to the week, month or longer note that holds the note's date — among the journals on the same shelf, or every journal when it is on no shelf, with custom interval journals left out — or Move task to a period's note to pick any journal and date, from any note. When more than one note qualifies, or the period has notelets, you pick which, and two journals of the same length are told apart by name; a period note that does not exist yet is created. The task brings everything nested under it, and a parent it sits under comes along as context and stays as it was. Any status can be moved, but a task already marked as rolled over, or nested under one that is, is refused — before any question is asked, as is a line that is not a task. The commands work from a note open for editing, not one in reading mode. The destination journal's Roll over settings decide what happens: copy and mark the original, or move it out, and the Target heading to land under, otherwise the end of the note. Under move, a task with a block link asks before anything is written, since moving it breaks links that point to it. Both notes are edited through their open editors, in any window, when they have one, so unsaved typing is kept and one undo reverses each change, and the destination is saved before the original is touched; if the task changed, or lines were added or removed above it, after it was copied, the original is left alone and the notice says the task was copied but not marked or removed. See Moving one task in the manual.
• A journal can now roll its unfinished tasks forward on its own. Turn on Automatic rollover in the journal's Roll over settings and, whenever the note for the current period exists, the open tasks of its earlier notes are taken into it with no command run — once Obsidian has loaded the vault, at midnight, whenever you come back to Obsidian (so a computer that slept through midnight still rolls on waking), and when the current period's note is added, by you, another plugin or sync. Each look first waits until no file has been created, changed, renamed or deleted for five seconds, and after loading or a return to Obsidian it starts that wait only after 30 seconds, so a sync already under way can land before anything is read; a sync that starts later still races the roll. A vault still busy after a minute is not read, and the wait starts again. It keeps rolling all period: a task added to yesterday's note in the afternoon rolls at the next look, while a note made ahead of time gets nothing until its period arrives. It never creates a note, and it needs Move, or Copy with Mark as rolled on; a journal that drifts into copying without marking, say through a changed default, pauses with one notice. Every notice it shows names the journal, except the one saying the rolled marker can't be read, which covers every journal. A roll that writes shows the usual notice and one that finds nothing stays silent; other warnings show once per note until Obsidian restarts. An earlier note that could not be updated, or that changed while it was rolled, pauses that journal rather than copying the same tasks again, with a notice naming every note affected; a roll that fails part-way pauses it too, with a notice of its own, and so does a run of Roll over unfinished tasks that leaves an earlier note not updated. A run of that command that reads every earlier note and updates every one it took from resumes it; renaming the journal does not. A task the current note already holds line for line is not copied again, though its original is still marked or removed — so a roll that runs again after an earlier note could not be marked does not copy twice, and an unfinished task matching one the note's template wrote is taken up by it. Two devices that both roll before either syncs write identical lines, but an edit in between, or a sync merge that does not combine identical insertions, can leave tasks in today's note twice; nothing is lost when that happens. See Automatic rollover in the manual.

Bug Fixes

• The decoration editor's style canvas now draws its preview lined up with the regions you click, instead of overhanging them whenever the editor was too narrow for the full-size canvas — which a 960px-wide window already was. The canvas shrinks to fit its column instead.
• Plugin API consumers no longer receive noteAdded and noteRemoved for a note that does not exist whenever a code block preview is shown in a journal's settings.
• Deleting one of two notes for the same date — the original of a sync-conflict pair, say — now leaves the other one in its place. Until now the calendar, navigation and the plugin API's notesFor reported no note for that date until the journal was next re-read, usually at restart, and the copy stayed reachable only by opening it. Plugin API consumers receive noteAdded for the copy, with canonical: true.
• Today's note arriving while a journal's code block preview was open in settings — by sync, from another plugin, or created by Journals — no longer goes missing once settings close. The preview held today's date in its place, so the real note counted as a duplicate, and after the preview closed the calendar and notesFor reported no note for today until the journal was next re-read.
• A setting that can't be read no longer resets everything around it. A navigation block keeps its other segments, the calendar display or startup section keeps its other options, a notelet type keeps its folder, templates and counter, a decoration keeps its other styles, a shelf keeps its other decorations; only the unreadable value goes back to its default or is left out. A decoration with an unreadable condition is still dropped whole, so it never marks days it wasn't set up to mark. A tasks setting — a listing filter, which checkbox items count as tasks, Dated tasks or Task notes — keeps an unreadable part as it was stored and treats it as matching nothing, so it shows less rather than more, and its editor says which part can't be read; an unreadable entry inside a Dated tasks or Task notes condition's list is left out instead. A view block with one unreadable setting now shows with that setting at its default, instead of an error saying its settings are not valid. The error stays for an unreadable choice of journals, notelet types, task sources or hidden weekdays, whose default would show everything that choice left out, and for a tasks block's unreadable depth.
• One unreadable toolbar item no longer hides the whole toolbar, or erases its other items the next time the toolbar is edited. A button or navigation item whose action can't be read is still left out, rather than shown with its own label over a different action.
• A shape or icon at the edge of a calendar day no longer draws over the selected date's ring. A dot at the bottom center used to cut straight through it, and the other edge placements overlapped it by a pixel or two; every edge placement now sits a pixel inside the ring, and the date number moves in to match, so a calendar whose decorations use edge placements grows a few pixels taller. Navigation blocks and timelines keep the same margin, so marks there sit a little further from the edge than before.
• On Obsidian 1.12 and later, a heading inside a dialog — the dry-run banner of Process bulk add, or the sections of an import preview — no longer sits indented from the settings below it. And a choice of buttons, such as a Check interval offset condition's Count from choice or a border's sides, no longer breaks onto a second line in a narrow row; the row's description wraps instead.
• A collapsible section's heading — the sections of a journal's or shelf's settings page, the blocks of the main settings page, the maintenance check's groups — can now be reached with Tab and opened or closed with Enter or Space, and tells a screen reader whether it is open. It could only be clicked before, so a keyboard alone could not reach anything inside a closed section.

Changed

• Check if note has open tasks and Check if all tasks are completed are replaced by Check tasks, and your existing decorations are converted automatically on upgrade to Any · Open and All · Done, both looking in the note and its notelets. Two things follow on days you already decorate. Task decorations now honour the journal's task filter, so on a journal that has one, some dots go dark — the listing always did this. They also now read the period's notelets, so some dots light that did not.
• A checkbox task marker other than a space no longer reads as completed by default. Every task used to count as done as soon as it carried any marker at all — task !== " " — so a note whose only task was - [/] ... satisfied Check if all tasks are completed and never Check if note has open tasks. Checkbox tasks are now read through a status map: x and X still read as Done and - still reads as Cancelled, all three still completed, but / now reads as In progress and any marker the map does not name — a theme's [>], for instance — reads as To-do; both are open, not completed. The main settings page now has a Tasks section listing one row per way Journals can find tasks, each with its own on/off toggle; Checkbox tasks' gear icon opens Status symbols, where you map a marker yourself if your vault's convention should read differently, alongside the identification rule for which checkbox items count as tasks at all. A journal gets its own Tasks section too, where Checkbox tasks' Edit button narrows or replaces the vault-wide rule for that journal alone. See Tasks in the manual.