- Date: 2026-08-26
- Type: Enhancement
- Priority: Medium
Problem
When multiple cloud conflicts occur for the same note, ZenNotes creates separate conflict notes such as:
2026-08-26 Wed (cloud conflict)
2026-08-26 Wed (cloud conflict 2)
These files appear to be duplicate versions of the original notes, but they do not provide enough information to understand what caused the conflict or what differs between the local and cloud versions.
As a result, there is no clear way to determine which changes should be kept or how the conflicts should be resolved. The only practical workaround is currently to delete the generated conflict files.
Proposed Enhancement
ZenNotes should provide a dedicated Cloud Conflict Resolution View instead of creating separate cloud conflict, cloud conflict 2, etc. files in the vault.
When conflicts are detected, the resolution view should display all files that have unresolved conflicts.
Selecting a conflicting file should open a diff view for that specific file, showing the differences between the local version and the cloud version.
The diff view should clearly distinguish:
- Local changes
- Cloud changes
- Conflicting changes
The user should then be given clear actions for resolving the selected file:
- Keep Local Changes — keep the local version and discard the conflicting cloud changes.
- Keep Cloud Changes — keep the cloud version and discard the conflicting local changes.
- Manually Merge — allow the user to review individual differences and choose which changes to keep from each version.
Conflict Resolution Workflow
The resolution view should guide the user through each conflicted file.
Once the user resolves the current file, its resolved version should be applied to the vault and the file should be marked as resolved. ZenNotes should then automatically continue to the next unresolved file.
For Manually Merge, the user should be able to review individual conflicting changes and select which version to keep rather than having to choose the entire local or cloud version.
Once all conflicts have been resolved, the Cloud Conflict Resolution view can be closed.
Deferring Conflicts
The user should also have a Resolve Later option when they do not want to resolve a conflict immediately.
Deferring a conflict should:
- Keep the conflicting data safely stored.
- Not delete the conflicting data.
- Keep the conflict available to resolve later.
- Keep the conflicting content isolated from the normal vault until it is resolved.
If the user attempts to leave the resolution view while unresolved conflicts remain, ZenNotes should clearly warn them that unresolved conflicts remain.
The user should be able to either:
- Continue Resolving the conflicts; or
- Resolve Later, with the current progress preserved.
The conflict resolution workflow should not silently discard unresolved conflicts or lose the user's progress.
Task Isolation
If a conflicted file contains tasks, those tasks should remain isolated from the normal task system while the conflict is unresolved.
Conflicting tasks should not appear in:
- Tasks views.
- Calendar views.
- Kanban boards.
- Other interfaces that display active tasks from the local vault.
This prevents tasks from an unresolved cloud version from interfering with the user's existing local tasks.
Once the conflict is resolved, only the tasks from the selected or manually merged version should become part of the normal task system.
Example
Instead of creating:
2026-08-26 Wed (cloud conflict)
2026-08-26 Wed (cloud conflict 2)
ZenNotes would open:
The selected file would then display:
If the user chooses to manually merge:
After resolving the file, the view would automatically continue to the next conflicted file:
Considerations
- Conflicts should be represented in a dedicated resolution interface rather than as additional notes in the vault.
- Multiple conflicted files should be accessible from the same resolution view.
- The selected file should have its own local-vs-cloud diff.
- The resolution view should indicate which files have been resolved and which remain unresolved.
- Resolving one file should automatically continue to the next unresolved file.
- Manual merging should allow individual conflicting changes to be selected.
- Deferred conflicts should remain available for later resolution.
- Unresolved conflict data should remain isolated from the normal vault.
- Conflicting tasks should not appear in normal task-related views until their conflict has been resolved.
- Leaving the resolution workflow with unresolved conflicts should require explicit confirmation.
- The user's progress should be preserved if they choose to resolve the remaining conflicts later.
Rationale
The current approach exposes cloud conflicts as duplicate files without giving the user enough information to understand or resolve them.
A dedicated conflict-resolution view would provide a clear workflow for handling multiple conflicts without polluting the vault with cloud conflict, cloud conflict 2, etc. files.
A diff view would allow users to see exactly what changed locally and what changed in the cloud, while the resolution actions would give them control over which changes are retained.
Automatically moving to the next conflicted file would also make resolving several conflicts more efficient, while allowing users to defer unresolved conflicts ensures that they do not have to finish the entire process immediately.
Current Workaround
The current workaround is to delete the generated conflict files after checking that the desired version of the original note is still available.
However, this does not properly resolve the conflicts because there is currently no way to determine what changes were contained in the conflicting versions before deleting them.
Additional Context
This occurred while both the ZenNotes desktop and mobile applications were online at the same time and connected to the same ZenNotes Cloud vault.
A new daily note was created on the desktop client. I did not create a new daily note on the mobile application. Despite this, multiple cloud conflict files were generated and automatically synced to the mobile application.
The generated conflict files were duplicate versions of the daily note:
2026-08-26 Wed (cloud conflict)
2026-08-26 Wed (cloud conflict 2)
The fact that the conflict files retained the same date and title as the daily note indicates that the conflict originated from the 2026-08-26 Wed daily note.
It is unclear what specifically caused the conflict. One possibility is that tasks from the previous day's daily note that had not been completed were automatically rolled over into the new daily note, and that these changes may have contributed to the conflict. However, there is currently no way to confirm whether this was the cause.
The generated conflict files do not show enough information to determine what caused the conflict, which changes came from the local or cloud version, what differs between the versions, or how the conflict should be resolved.
Because of this, the conflict files ultimately have to be deleted without being properly resolved.
Problem
When multiple cloud conflicts occur for the same note, ZenNotes creates separate conflict notes such as:
These files appear to be duplicate versions of the original notes, but they do not provide enough information to understand what caused the conflict or what differs between the local and cloud versions.
As a result, there is no clear way to determine which changes should be kept or how the conflicts should be resolved. The only practical workaround is currently to delete the generated conflict files.
Proposed Enhancement
ZenNotes should provide a dedicated Cloud Conflict Resolution View instead of creating separate
cloud conflict,cloud conflict 2, etc. files in the vault.When conflicts are detected, the resolution view should display all files that have unresolved conflicts.
Selecting a conflicting file should open a diff view for that specific file, showing the differences between the local version and the cloud version.
The diff view should clearly distinguish:
The user should then be given clear actions for resolving the selected file:
Conflict Resolution Workflow
The resolution view should guide the user through each conflicted file.
Once the user resolves the current file, its resolved version should be applied to the vault and the file should be marked as resolved. ZenNotes should then automatically continue to the next unresolved file.
For Manually Merge, the user should be able to review individual conflicting changes and select which version to keep rather than having to choose the entire local or cloud version.
Once all conflicts have been resolved, the Cloud Conflict Resolution view can be closed.
Deferring Conflicts
The user should also have a Resolve Later option when they do not want to resolve a conflict immediately.
Deferring a conflict should:
If the user attempts to leave the resolution view while unresolved conflicts remain, ZenNotes should clearly warn them that unresolved conflicts remain.
The user should be able to either:
The conflict resolution workflow should not silently discard unresolved conflicts or lose the user's progress.
Task Isolation
If a conflicted file contains tasks, those tasks should remain isolated from the normal task system while the conflict is unresolved.
Conflicting tasks should not appear in:
This prevents tasks from an unresolved cloud version from interfering with the user's existing local tasks.
Once the conflict is resolved, only the tasks from the selected or manually merged version should become part of the normal task system.
Example
Instead of creating:
ZenNotes would open:
The selected file would then display:
If the user chooses to manually merge:
After resolving the file, the view would automatically continue to the next conflicted file:
Considerations
Rationale
The current approach exposes cloud conflicts as duplicate files without giving the user enough information to understand or resolve them.
A dedicated conflict-resolution view would provide a clear workflow for handling multiple conflicts without polluting the vault with
cloud conflict,cloud conflict 2, etc. files.A diff view would allow users to see exactly what changed locally and what changed in the cloud, while the resolution actions would give them control over which changes are retained.
Automatically moving to the next conflicted file would also make resolving several conflicts more efficient, while allowing users to defer unresolved conflicts ensures that they do not have to finish the entire process immediately.
Current Workaround
The current workaround is to delete the generated conflict files after checking that the desired version of the original note is still available.
However, this does not properly resolve the conflicts because there is currently no way to determine what changes were contained in the conflicting versions before deleting them.
Additional Context
This occurred while both the ZenNotes desktop and mobile applications were online at the same time and connected to the same ZenNotes Cloud vault.
A new daily note was created on the desktop client. I did not create a new daily note on the mobile application. Despite this, multiple cloud conflict files were generated and automatically synced to the mobile application.
The generated conflict files were duplicate versions of the daily note:
The fact that the conflict files retained the same date and title as the daily note indicates that the conflict originated from the
2026-08-26 Weddaily note.It is unclear what specifically caused the conflict. One possibility is that tasks from the previous day's daily note that had not been completed were automatically rolled over into the new daily note, and that these changes may have contributed to the conflict. However, there is currently no way to confirm whether this was the cause.
The generated conflict files do not show enough information to determine what caused the conflict, which changes came from the local or cloud version, what differs between the versions, or how the conflict should be resolved.
Because of this, the conflict files ultimately have to be deleted without being properly resolved.