Feature Ideas

Add comments and link entities from media highlight text in PDFs and link content add comments to Audio and Video at a certain time add comments to images at specific coordinates Additional features: speech-to-text translation entity and text recognition in images ...

One of the recent updates brought back some flaky operations in the way outlines work. Was working fine, but one of the last few updates broke it. Create new outline item, make it level 2, enter, tab...should now be NORMAL item under the heading level but it's still level 2, having to grab the mouse, hover, select normal, and continue is awkward and, IMO, broken. This happened a while ago, got fixed, is broken again Should be: if I make an outline item level 2, then new item at same level is also a 2, assume I'm setting up the different sections with heading all of the same level, but when I create a new item and indent, then it becomes normal because the assumption is that now I'm creating the content under that level

Would be wonderful if we could search through the content of pdf files.

OpenAI's Whisper model does a great job at taking voice recordings and transcribing them perfectly. This can be great for transcribing meetings or voice notes for quick capture. It would even be cool to take voice recordings from Telegram voice notes or WhatsApp.

I've uploaded multiple PDFs that all shoe "PDF cannot be displayed" but can be opened on web. Because of this I basically have multiple "Untitled" PDFs that have no metadata I can use to know what I'm referencing.

Note: Captured screen of CSV file for reference. I tried importing CSV file into Capacities for 'Daily note' object type. As of now, got Capacities to create an entry on a correct date, but unfortunately, with no content. Note that I've contacted Capacities support team via email and was guided to try a bunch of CSV headers with no luck: Header-1: 'created_at' -> This got Capacities to create an entry on a correct date for 'Daily note'. I used format yyyy-mm-dd to indicate which date I wanted to create Daily note. Header-2: neither 'text', 'content', 'daily_note', 'notes', 'body' worked. Data was not mapped into content of Daily note.

On iOS I can‘t delete a new line at the beginning of a sentence. But sometimes when I copied text from a webpage, there are line-breaks where I don‘t want them. But I need to open the desktop app to delete this line-break!

Current Behavior: The browser tab and desktop app title bar both show a static "Capacities" regardless of which space, object, or daily note is open. Desired Behavior: Reflect the active context in the document title. For example: Capacities – Organization: Microsoft Capacities – Daily Notes: 06/23/2026 Capacities – Page: Q3 Planning Motivation: I use a time tracker that logs both URLs and window/tab titles. URL-based tracking works for the web version, but the static title makes it impossible to derive what I was working on from the title alone — which breaks title-based logging entirely. Dynamic titles would make Capacities natively compatible with most time-tracking and productivity workflows without any user-side configuration. Scope: Web: Update the tag dynamically as the user navigates between objects and spaces. Desktop: Update the window title bar. If the app uses Electron or a comparable wrapper, this is likely achievable via BrowserWindow.setTitle() — but happy to defer to the team's judgment on feasibility.

Hi Capacities team, Thank you for the great work on Capacities — I use it daily and really enjoy it. I'd like to report a small issue with the built-in PDF viewer. When I open a PDF and change the zoom level, some pages occasionally become blurry, while other pages in the same document stay sharp. This happens both when zooming in and when zooming out. It doesn't occur every time, but it does show up now and then. I've attached a screenshot as an example: page 1 is clearly blurrier than page 2, even though both are displayed at the same zoom level. It looks as though the affected pages are not being re-rendered after the zoom level changes. For reference, the PDF is not a scanned document. It was generated by an AI assistant (Copilot) as a translated version of a web page, so the pages contain digitally rendered text rather than scanned images. Scrolling away and back sometimes restores the sharpness, but not always. Please let me know if any further details would be helpful — I'd be happy to provide them. Thanks a lot for looking into this! Best regards, Capacities v1.67.19; none none; Windows v10; Chrome v146.0.7680.216 (WebKit v537.36); Desktop (Electron); 2026/8/4 14:35:37; en (Asia/Shanghai, UTC+8); Memory: 113.23 MB / 4 GB; Storage: 359.89 MB / 9.39 GB; Portal: reachable; S3: reachable; Dead Workers: none

I am using Claude to create tasks via the API. I would occassionally get the wrong date. I made the prompt super specific and Claude reported the following: Is this correct, and if so, is there a planned fix? "Task created without the date field due to a validation bug in the date/deadline setter (it kept demanding a date one day earlier than whatever I supplied, an unsatisfiable moving target). Now patching in the due date directly via markdown frontmatter to bypass that path.Confirmed: the date is now correctly stored as 2026-08-03T00:00:00.000Z (today). No status set, priority Low, as required.Found 1 Fieldy conversation in the past hour and extracted 1 task: Test the transfer of files — created in Capacities, due 2026-08-03, low priority, no status. Link Note: Capacities' date-setting had an off-by-one-day bug (both via the createTask date param and the raw frontmatter path), consistently storing one day earlier than requested. Worked around it by writing "2026-08-04" to the frontmatter, which correctly resolved to 2026-08-03 — verified via a follow-up read."

Summary When setting an entity-relation property (any property on an object type that links to other objects) through the Markdown import API, the value is matched to existing objects by title string, and that title parsing is lossy. Target titles containing commas or apostrophes get split or altered before matching, so instead of linking to the existing object the API silently creates a new, wrongly-titled object. This corrupts the space with duplicate/junk entries and returns no error. Environment Capacities Public API, POST /object/markdown (also reached via the official MCP connector's createObjectViaMD / updateObjectViaMD). The relation is written as YAML frontmatter, where the value is one or more linked-object titles, e.g. : "Some Existing Object Title". Reproduction In any space, have an existing object whose title contains a comma, e.g. Alpha, Beta and Gamma. On a second object, set an entity-relation property (that points at the first object's type) to that exact title string via the API. Observe the result. Expected: the relation links to the existing object. Actual: the title is split on its comma into fragments ("Alpha" / "Beta and Gamma"), each fragment is treated as a separate target title, no match is found, and the API creates new junk objects from the fragments. Three distinct failure triggers we've confirmed Comma outside parentheses — the value is split on commas, so any target title containing a comma is broken into fragments, each spawning a junk object. This includes commas inside numbers (e.g. a title beginning 20,000 … splits into "20" and "000 …"). Apostrophe / typographic quotes — a straight apostrophe (and curly quotes) is stripped from the title before matching. A target like One Mom's Battle is matched as "One Moms Battle," fails to find the real object, and creates a junk object under the stripped title. Colons and question marks are handled correctly, so the issue is specifically comma-splitting and apostrophe/quote stripping — not punctuation in general. Additional trigger — updating a relation that already has entries When updating an entity-relation on an object that already holds linked items, the API replaces the whole property, and to preserve the existing links you must resend the full set of titles. If any already-linked target has a comma or apostrophe in its title, that round-trip re-mangles it — so a single update can corrupt links that were previously fine. This makes it unsafe to programmatically add one item to a relation whose existing members have "unsafe" titles. Root-cause hypothesis The import pipeline appears to (a) tokenize the relation value by splitting on commas rather than treating a quoted string as one atomic title, and (b) normalize titles by stripping punctuation before the existing-object lookup without normalizing the lookup index the same way — so legitimate titles never match and fall through to "create a new object." Impact Any programmatic linking to objects whose titles contain commas or apostrophes — very common in real-world titles and names — silently produces duplicates and orphaned fragments, with no error surfaced. It reads as success. Cleanup is manual. Suggested fixes (any one helps; all three would be ideal) Treat a quoted YAML string (or each explicit list item) as a single atomic title; only split on commas when the value is genuinely a bare comma-separated list, never inside quotes. When matching a relation value to an existing object, normalize the input and the index identically (or match on the raw title) so apostrophes/quotes don't cause a miss. Allow referencing target objects by object ID in relation writes, not only by title. This is the robust fix — it removes the fragile title round-trip entirely. Today the API accepts only titles for these links, which is what forces the lossy matching. Two secondary items worth noting Search recall: the API search sometimes fails to return an object that clearly exists (an exact-phrase search missed an object whose stored title had extra words appended), which makes reliable dedup-before-create hard. Improving exact-title recall would help. Non-reciprocal relations: where two object types each have a relation pointing at the other, setting one side via the API does not populate the other side — they're independent one-directional properties. That may be intentional, but an option to define a relation as bidirectional (one write fills both sides) would be valuable.