Macsparky recently released his Robot Assistant Field Guide, which is basically built around using Claude Cowork and Obsidian. An email from him this morning noted that people are asking if they can still do this without using Obsidian. He released a video saying yes, you can, with Noteplan or DEVONthink. The video shows how to set it up: https://www.youtube.com/watch?v=Kq6sv0oXAPc.
I have been building out some pretty good Cowork workflows, to the point that I have even gone back to indexing some data in DEVONthink so I can use Cowork, all the while wishing I could somehow use both without the indexing.
Well, according to David Sparks, you can do that. In the video at about 8:45, he points Cowork to his CLAUDE.md file in the DT internals.
MY QUESTION: isn’t this not a good idea? From the poking around I’ve done in the db internals over the years, files in a given database are not all in the same file directory and are scattered all over the internal structure. Wouldn’t doing something like this screw up the database? If not, that would be great because while I have not dealt with any indexing horror stories like others have, I am well aware that the indexing setup is much more fragile and would like to avoid it if possible.
Also, one major failure point I see is there is not one directory of files in the internals of a database. His 2e folder is a subdirectory in a larger structure. For example, here is the rtf directory in a database…
So if you only point at one folder, you’re missing the rest.
Also, file locations in the internals are not necessarily static.
In this case, indexing into a database (done with forethought) is the better option.
But reiterating @cgrunenberg’s point, we do not support messing about in the internals of a database. As the old saying goes, “You break it, you bought it.”
Just as I thought. This is precisely why I went the index route while messing with my new workflows. Too bad, though! It would be great if I would just point Cowork directly at a DT non-indexed database and go crazy.
I see the enthusiasm but also think, “That’s all my information going to some unknown server and process.” Personally, I’m not a fan of giving AI that kind of access. It puts me in mind of wise words from 1755, replacing Liberty with privacy and Safety with convenience…
Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety.
~ Benjamin Franklin
We certainly agree some pretty cool things are now possible. But not only for ourselves but for all of you, we take the safe road re: data privacy and safety. Most people have more important data than kayaking PDFs and web clippings about Pickled Cucumbers in their databases (common examples of mine)
Totally agree with not exploring the DT database directly - either manually or with automation. Clearly David knows that. Maybe he meant something different?
However - with regard to using Cowork with Devonthink overall I have been exploring it recently and the benefits are profound. I will be making a more detailed post after I work with it a bit more- but I do suggest you give it a try and reconsider your stance.
Bottom line - Using Cowork has 10 times more benefit than Applescript or JXA with no increased risk. And so much easier than writing Applescript or JXA. Even easiser than vibe coding.
You can use Cowork either with the “Unofficial Devonthink MCP” or you can use it by itself with Devonthink and let it write its own Applescript or you can write your own Applescript/JXA and restrict Cowork just to that.
Most notably - you can restrict it only to a particular group/subgroups or only to a particular database. That lets you experiment/learn without risk of damaging production data.
Cowork does all sorts of things not possible with Devonthink alone- including:
(1) Flat-fee AI access to Devonthink as part of your Claude Desktop account - no extra API fees
(2) Integration with external APIs, SAAS tools, websites, and MCP servers of your choice
(3) Ability to run multiple scripting workflows in parallel - and edit/revise them while they are running if necessary
(4) Very convenient remote access to advanced Devonthink features using your iPhone and Claude Desktop on your home computer (arguably much more capable than DTTG) - called Claude Dispatch
(5) Extremely convenient scheduling of daily workflows to either analyze / report on Devonthink documents or use Devonthink as a central hub to store ongoing daily AI agent research
(6) Ability to run very long workflows without DT4 timeouts
(7) Abiltiy to use Tesseract for OCR - thus allowing use of languages that Devonthink OCR does not support or allowing you to exceed the 10,000 page-per-month limit of Devonthink/Abby OCR - for free
…. and so much more.
This is what I can do now without formal Devontech support of Cowork - lord knows what else it could do if it were officially supported.
Cowork has much more realistic guardrails than OpenClaw. Given that DT4 already supports Applescript and JXA, I don’t see much additional risk to using Claude Cowork with DT4. At minimum it is worth trying out with a dedicated database. I believe it is a profound increase in what can be done with Devonthink.
This is impossible to declare. Hope for? Sure, but it’s certainly not assured, in the least. Everyone has to decide on their own level of privacy and security but they should also consider the potential repercussions of a laissez-faire approach to it.
You are also presenting a list of things important to you. You’re coming at it from a very unique perspective and with more experience with AI than most, I’d imagine. These are not the needs and requirements of many(probably most) people using DEVONthink. In fact, none of the items you list are applicable to my use of DEVONthink, professionally or personally.
Remember our app isn’t built for one person or one group of people. If 10 people want Cowork and 1000 want their Favorites and preferences to sync between their Macs, which should be our focus? (And not everyone is so enamoured with AI. I get tickets each month with people not wanting any AI at all.) We are all investigating and learning and discussing AI-related things, but ultimately these are decisions for development and our CTO.
And this still stands…
Again… data safety – including the integrity of peoples’ databases – and data privacy are our overriding concerns and focus. Access to external AI in DEVONthink was and is carefully and thoughtfully implemented with those things in mind. The features and functions will evolve naturally and safely within our boundaries.
Who will get the support tickets and complaints:
if Cowork moves and deletes items because “there’s no real risk”: Anthropic or us? (And no, indexing isn’t automatically a “safe” option.)
What if it adds a flurry of files inside a database or decides the built-in structure doesn’t make sense and refiles the Files.noindex directory by names and dates, breaking the database in the process?
When the integration with the “external APIs, SAAS tools, websites, and MCP servers of your choice” doesn’t work…
The AI-generated scripts don’t work (and yes, I already get these and tickets with AI-generated “investigation” with errors and misdirections)…
etc.
Who’s doorstep are these issues landing on? Ours and it’s a legitimate concern, not only for us but for the people affected.
If people do things to expose their information, we can’t stop it. And if people do things and break their databases, we also can’t stop that. We aren’t responsible for the results of those actions… but we will also be the ones being asked “to put Humpty Dumpty back together again”.
So while enthusiasm and sharing is fine, we have deeper and broader things we corporately need to consider than whether something is just “fun” or “cool” or “possible”. Things to think about.
I totally understand that - and I very much respect and appreciate your approach to privacy.
My key point is that you already support Applescript and JXA; therefore the cat is already out of the bag.
CoWork already works with DT4. So the question seems to be - would you prefer to have CoWork using random scripts that it creates to integrate with DT4 or would you prefer to have CoWork use scripts which are part of an MCP server written by DevonTech? Or perhaps as simple as your looking at the existing “unofficial” MCP server and either giving it your blessing or proposing fixes to make it more secure?
That said - there is no doubt in my mind this is going to take off big-time among DT4 users. You say that none of the items I listed are likely of use to you or most of your users. There is one exception - With CoWork you can use DT4 and AI for the same flat-rate subscription that you use for Claude AI/Claude Desktop. No more API fees. That is a request that has frequently appeared in the Forum. The floodgates are open - and you will not be able to hold that one back.
From what I’ve been reading, the consensus seems to be that all forms of “vibe coding” are extremely dangerous unless the human reviewing the code is knowledgeable enough (and diligent enough) to detect potential problems.
That most definitely includes the ability (and willingness) to vet any external tools that are being incorporated. Claude is known to call APIs that don’t exist, and malicious actors are known to exploit that failing to inject malware.
You personally may be quite capable of understanding the risks, but that’s the kind of potential risk that gives software support teams nightmares.
That said - I am using it with very lengthy documents and a fairly complex reporting template. With Claude CoWork I can do work that previously required a custom web app or custom DT4 script and API access.
The money I will save by reducing my API costs will far exceed the extra cost to go from Claude Pro to Claude Max. I suspect a more typical user will be fine with the basic Claude Pro at $20/month.
Plus the Claude Max plans use Opus for more complex tasks; under API rates Opus would be impractical for me so I rarely went beyond Sonnet.
