have a fairly large Devonthink database (around 4.9GB), one of several I maintain. Over time it’s become a bit of a dumping ground, with multiple folder structures layered on top of each other, and I’d like to reset it and organise it properly.
My current thinking is to use Claude CoWork to help with the heavy lifting. As some of you may know, it can analyse files, suggest structures, and handle bulk renaming.
The rough plan is:
• Export all files from DEVONthink into a folder in Finder (effectively creating a mirror of the database outside the app)
• Have Claude Cowork analyse that folder and propose:
• a cleaner folder structure
• consistent file naming
• Review its suggestions first (no changes applied initially)
• If it all looks sensible, allow it to reorganise and rename the files
• Create a new DEVONthink database and import the cleaned structure
• Keep the original database as a read-only archive for safety
Before I attempt this, I’d really appreciate some advice:
• What’s the best way to export everything from Devonthink while preserving structure?
• Are there any pitfalls with this approach (metadata loss, links, duplicates, etc.)?
• Has anyone tried a similar “external clean-up and re-import” workflow?
I’m unaware of how Claude CoWork works or even what it is.
There is the Menu: File → Export → Files and Folders … command. Might be the best. Try it and see if it meets your expectations. You can read about it in the DEVONthink Manual and/or Help in the “Export” Section.
Perhaps you can experiment and try your ideas, re-importing the results into a new database so as to not destroy the source data base. Be interesting if you report back success or failure here.
I’d probably do the work manually rather than rely on an AI tool–that’s just me. I rely on DEVONthink’s features to interrogate the database when looking for something.
Yes that sounds like a sensible approach - I suppose I am wondering if I just drag all of the top level folders from within Devonthink database to a new folder in the finder will there be anything which will not be copied across that I might not be aware of. But of course I can test and see thank you
UUIDs will definitely change and therefore any existing item links will break. In addition, metadata like flags, labels, long comments or the connection between documents and their annotations etc. might be lost.
Batch processing could easily handle this using the Change Name action. By default there’s already a configuration for AI-based renaming.
This is not a simple exercise. I have had Claude organize a relatively small hierarchy of folders and documents. It required multiple iterations, refinement of prompts, and dead-ends where Claude simply could not understand my intentions for structure because it does not understand the nuances of why I had the documents to begin with, insisting I do things I knew I didn’t want. I ended up doing chunks of the work myself, and asking Claude to review my work and make suggestions.
With the amount of data you have, you are going to have the same problems with a order of magnitude more complexity, involving hours, perhaps days, and a lot of tokens.
Step back and consider why you think your database is disorganized, work out an ideal destination on. your own, and what you can do on your own. If you can break down the problem into subsets without attempting to work with the robot to organize the entire dataset, you might find you get to an acceptable solution faster.
it sounds like a cool project — would be interested in the results!
personally, I have given up on trying to create a “perfect” directories structure — instead, I rely on search + tags + loose groups structure in the DEVONthink. works for me so far!
Yes totally agree re ‘perfect’ structure for sure. I started the database many years ago and have probably over engineered a bit so there are duplicate folders and duplicate places to place things etc … I think I want to approach the re structuring so that cognitively I can make sense of where things are in a broad sense .. at the moment it is a real jungle of documents so more looking to get a fresh start on my structure so that when I look at it it makes some kind of sense to me so that it hopefully shapes my thinking a bit better seeing a broad structure that makes sense to me
Claude CoWork could do it if you use the unofficial DT4 MCP server.
But I do not recommend that for this.
I think you would have better results if you export your data to finder, have Claude work on the data in the Finder (which it is designed to do well), and then re-import the data to DT4.
Organizing and renaming files with Claude CoWork or Claude Code on the Mac can work very well, depending on the prompt and the structure of the files. Two weeks ago, I used Claude Code to organize more than 110 files from a legal case within minutes by date, sender, recipient, and subject matter.
So for plain file-system work in Finder, this is already a fairly common use case. The real bottleneck, in my view, is not Claude’s ability to sort or rename files, but the risks others have already mentioned once data is exported from DEVONthink. If preserving item links, tags, and database metadata is important, that part deserves real caution. If those aspects are not relevant in your case, the Finder route may be a practical option.
Sure. In my example, it was a legal case with 110+ files.
The structure itself was flexible: Claude could either keep everything in one folder and just rename the files consistently, or split them into folders like Court, Correspondence, Authorities, Evidence, Decisions, etc.
File names could then follow a pattern like YYYY-MM-DD_Sender_Recipient_Topic.pdf.
That was exactly why I used it: I did not have to build an automation first. I could just describe the logic in plain language — date, sender, recipient, matter/topic — and Claude handled the reorganization very quickly without me touching every file manually.
Afterward, the result can still be brought back into DEVONthink by import or index, depending on how you want to manage it.
Since I already work with Claude Code and the terminal a lot, that was the most natural route for me. And for users who do not want to use the terminal, the same basic approach now also works via Claude CoWork in the Mac app.
For me, the bigger issue is not whether Claude can do the file handling, but whether exporting from DEVONthink is acceptable if DT metadata, tags, links, or database context need to be preserved.
and content, and file type, and language, and ancillary identifier such as tags or dates … and, and, and…. the variables in a ~5GB data set all have to be accounted for in the prompt and how the problem is structured.
Fair point. I am not saying Claude removes the complexity. With the same source files, I would have to handle the same variables in DEVONthink too.
The difference is mainly the interface: in DEVONthink I would probably solve it with automation, scripts, rules, maybe regex; in Claude Code I can express the same logic in natural language and let it execute the steps.
So for me this is not about the “better” tool. It is just a different workflow. Since I already work with Claude Code and the terminal all day, that route is more natural for me. For others, a DEVONthink-based workflow may be preferable. And sometimes a combination of both is probably the best option.
That is an intersting workflow - and I believe it is worthwhile to compare those options.
I believe it is possible to get good results reorganizing a database with LLM AI without exporting and re-importing data. I compared two techniques:
(1) First I used the LLM AI capabilitiles in AI—- by creating a Chat referencing a specific Group with a set of academic PDF articles. I asked Claude Opus 4.6 to create appropriate subgroups and tags, to create an overall Annotation summary with quotes/links to the specific documents, and to log all of its work:
The MCP server I installed was posted on this Forum by @syntagm and is available on Github:
There is also a fork of the same MCP server with some new features but I have not tried that yet:
The .zip files above give a good idea of the results using Opus with a DT4 AI chat vs. using Claude Cowork and the DT4 MCP server. The outcome was excellent in both cases - indeed the results were very similar.
I understand the MCP server is not endorsed by Devontech. Understanding your miileage may vary and caaveat emptor, I believe it works well and has appropriate guardrails. While the results here are similar when using the MCP server vs DT4 AI chat, I believe Claude Cowork has one feature which puts it ahead of DT4 Chat AI for some users: Custom LLM Tool Support.
I respect that DevonTech prioritizes data security very high and with a conservative approach to feature support. That said, custom tool suport means it is possible to configure Claude Cowork to perform actions on DT4 data not achievable natively with DT4. The sky is the limit as far as what could be built with custom tools for Claude or Opus - some examples I am considering include data enrichment through external APIs, Lanchain RefineChain summaries using Python libraries, and searching publilc custom databases.
Very interesting comparison — that is exactly the kind of workflow discussion I had in mind.
I did not know the MCP route before, but that looks very promising. If it works reliably in practice, export and re-import could indeed become unnecessary, which would obviously be a big plus where DEVONthink metadata, tags, links, or general database context matter.
The custom tool support point is also very interesting. Not because DT4 lacks native AI features — it clearly does not — but because Claude/MCP workflows can connect DT-based work with additional tools, APIs, databases, or custom processing steps within the same workflow.
To me, this really highlights the importance of choosing the workflow architecture that best fits the material, the risk tolerance, and the user’s normal way of working.