Artifacts can build a complete client-ready document, but they cannot deliver it anywhere. Because they run with no network access, an artifact that generates a quotation, invoice, or report has no way to attach the finished file back to the ClickUp task it was opened from. The user has to save a PDF locally, go find the task, and upload it by hand. That breaks what should be the most valuable artifact use case: operational documents that belong on a record.

To be clear about what I am not asking for. Calling the ClickUp API from artifact JavaScript would mean embedding an API token in the artifact source, where anyone who can view the artifact can read it. That is not acceptable. Neither is general outbound network access, which would let a malicious or prompt-injected artifact exfiltrate workspace data. The sandbox exists for good reasons and should stay.

What I am proposing instead is a narrow, host-mediated capability bridge. Expose a small API to artifact code where the ClickUp shell performs the action on the viewing user's behalf, under that user's own permissions, so the artifact never holds a credential and never makes an outbound request itself. Three verbs would cover almost every document workflow: attach a file to a task, post a comment on a task, and read the task, list, or doc the artifact was opened from.

This is safe by construction rather than by trust. There is no credential in the artifact source, so there is nothing to leak. The host enforces permissions, so a user can only write where they already have edit rights. The verbs are specific rather than arbitrary HTTP, so there is no exfiltration path. Every write happens through ClickUp and is therefore attributable in an audit trail. And each call can be gated behind a real user gesture, so nothing fires silently in the background.

Alongside that, please consider a host-level PDF export rendered server-side rather than through browser print, exposed both as a native Export PDF action in the artifact chrome and as a callable method. Browser printing of artifacts is currently unreliable and truncates output to a single page, and shared artifact links cannot be printed properly at all. Server-side headless rendering would produce correct multi-page A4 output with @page rules and print stylesheets honored, fixing the existing truncation bug and the shared-link printing reports in the same change.

We did try the alternative of having a Super Agent compose the document conversationally, since agents can already attach files. For anything with many line items and custom per-line detail it is slower than filling in a form, and dramatically slower on amendments, where you end up re-describing the whole quote instead of editing one field. Direct manipulation is simply the right interface for structured documents. The artifact is the correct tool here. It just needs one narrow, safe way to deliver its output.

The impact reaches well beyond our use case. Any artifact that produces a document, whether that is a quotation, invoice, SOW, certificate, report, or inspection form, would become an end-to-end workflow instead of a dead end.