[claude.ai] Artifacts sidebar conflates unrelated output types, with broken export naming and no granular toggle control
Preflight Checklist
- [x] I have searched existing requests and this feature hasn't been requested yet
- [x] This is a single feature request (not multiple features)
Problem Statement
Note: This issue concerns claude.ai (web/desktop), not Claude Code CLI. Filed here as there is no dedicated repo for the claude.ai product.
The Artifacts sidebar in claude.ai conflates fundamentally different output types under a single UI concept, creating confusion and daily friction for professional users.
What the sidebar shows vs. what it should show
The "Your creations" sidebar currently displays:
- Deep Research reports — yes
- Generated files (docx, pdf, xlsx) via code execution — no
- Interactive artifacts (React, HTML, SVG) — yes, if created
The feature most literally described as "file creation" (generating a docx via python-docx) is absent, while DR reports the user didn't author are labeled "your creations." The sidebar is effectively a Deep Research history disguised as a general-purpose artifact manager.
"Your creations" is the wrong label for DR output
When a user submits a DR query, Claude autonomously develops a research plan, searches sources, performs analysis, and synthesizes a report. The user asked a question — the system produced the output. Calling these "your creations" misrepresents the user's role.
Export generates unusable filenames
When downloading a DR report outside its project context, the system generates names like artifact-[hash].md instead of using the report title. This forces a manual workflow for every single export:
- Open the report
- Copy the title
- Paste as filename
- Remove filesystem-illegal characters (
:,?,", etc.)
DR titles are structurally incompatible with filenames: they are long, descriptive, and routinely contain colons, question marks, and quotation marks. There is no automated sanitization.
Why external file management is necessary
The natural response might be: "Just use Claude's built-in project files." This doesn't work for two independent reasons:
- Project files are read-only. Claude can read them but cannot write to, update, or delete them. Any iterative workflow requires external storage.
- Project files have no folder structure. It's a flat list — no folders, no hierarchy. Unusable for any real-world activity with more than ~10 files requiring categorical organization (dental practice, legal cases, research projects, any business operation).
These limitations push users to external file management (Google Drive, local filesystem), where the broken export naming creates compounding friction.
The toggle problem
The single "Code Execution and File Creation" toggle controls DR data processing, file generation, AND interactive artifacts. Users who depend on DR and file creation cannot disable interactive artifacts without losing core functionality. The toggle is effectively locked to "on."
Proposed Solution
Priority 1 — Fix export filenames (high impact, low effort):
Use the DR title as the default filename on export. Automatically sanitize for filesystem compatibility (replace illegal characters, truncate to reasonable length). This is standard behavior in virtually every application that exports named content.
Priority 2 — Sidebar improvements:
- Rename "Your creations" to something accurate ("Research reports," "Outputs," or type-specific labels)
- Either include generated files (docx/pdf/xlsx) in the sidebar or stop calling it a creations manager
- Allow filtering or categorizing by output type
Priority 3 — Toggle granularity:
- Allow hiding the Artifacts sidebar independently of the code execution toggle
- Separate toggles for Code Execution, Deep Research, and Interactive Artifacts
Priority 4 — Project file structure (larger lift):
- Support folders/subfolders within Projects
- Allow Claude to write to project files, not just read them
- These two changes would eliminate the need for external file management workarounds entirely
Alternative Solutions
Current workaround: I save all project files to a writable Google Drive folder, since Claude Project files are read-only and flat. This gives Claude full read/write access and allows real file organization with folders. However, the broken export naming means every DR report requires manual title extraction, character cleanup, and renaming before it can be properly filed.
No other AI tool I'm aware of solves this differently — the issue is specific to how claude.ai bundles and exports its outputs.
Priority
Medium - Would be very helpful
Feature Category
Other
Use Case Example
Real scenario (daily occurrence):
- I run a Deep Research query from within a Claude Project
- DR produces a comprehensive report titled e.g. "Analisi comparativa: strategie difensive nel sequestro conservativo ex art. 671 c.p.c."
- I need to save this report to my organized Google Drive project folder
- I click download — the file is named
artifact-abc123.md - I must manually: open the report, copy the title, paste as filename, remove the colon and any other illegal characters, save
- Repeat for every single DR report
This friction compounds across dozens of reports per project. The sidebar doesn't help organize them either — it shows DR reports mixed with other output types under the misleading label "Your creations."
The root cause is that Claude Projects have read-only, flat file storage — so external file management isn't a choice, it's a necessity. And the export pipeline doesn't account for this workflow.
Additional Context
- Plan: Max 20x
- Platform: Web (claude.ai) + Desktop app
- Primary workflow: Deep Research, document generation via computer use, project-based file management across multiple professional domains
- Interactive artifacts usage: never
- Similar frustration reported on Hacker News: https://news.ycombinator.com/item?id=44578329
- The term "artifact" itself is overloaded: it means both "any output in the side panel" and "interactive component you can publish/remix." This naming collision makes the feature harder to understand and harder to discuss in feedback.
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗