Share a file or page as a link

Files that live outside the usual project / ~/Claude / ~/.amc folders (for example a file path Claude produced that happens to point at your Desktop) are copied into Yardmaster's staging area automatically before being published, so you don't have to move them yourself.

If the link points at something Yardmaster can't resolve to a real file on disk (an Inbox or Calendar virtual project), you'll still see a friendly error toast explaining why.

Files from your Desktop, Downloads, or anywhere else outside the usual project folders are copied into Yardmaster's staging area automatically: no need to move them by hand first.

Mixed batches surface a single warning toast like "Published 3, 1 failed: foo.docx: …" instead of one toast per file (typical failures are unsupported file types like Office docs, not path errors).

HTML pages and React components published as shares execute scripts the way they would on Claude.ai: demos, interactive charts, and small tools work out of the box. Each share opens in an isolated browser sandbox: scripts can run, but they can't read other shares' storage, your Yardmaster data, or any other site's data. Markdown, code, and plain-text shares are still static (no script execution).

If someone opens your shared web page and it looks blank, an aggressive ad-, script-, or privacy-blocking browser extension on their end may be blocking the sandboxed content. The page now detects this and shows a small hint telling them to open the link in a private/incognito window or turn their blocker off for the page, so a blocked viewer gets a clear next step instead of a dead screen. Your share itself is fine; it's the viewer's extension doing the blocking.

Every link inside a share opens in a new tab, and it's a normal tab. The sandbox applies to the share itself, never to the site a viewer clicks through to, so a GitHub, Jira, or Google link in a shared dashboard signs in and loads exactly as it would from any other page.

Table-of-contents links (the ones that jump to a section of the same page) scroll instead, as you'd expect. Yardmaster leaves a link alone where you clearly meant something else: a download link, a mailto: or phone link, your own ctrl-click or middle-click, and any click the page's own code already handles.

Two earlier problems here are fixed, and both fixes were applied on the server, so nothing needs to be re-published. Before September 2026 a link opened from a share inherited the sandbox, which made the destination site look broken: sign-in ignored, status widgets stuck loading.

And until 9 September 2026, a link the page hadn't explicitly marked to open in a new tab did nothing at all when clicked (often blanking the share out) because the sandbox won't let a share navigate the tab it's sitting in.

One thing still won't work: a link pointing at a relative path, like /other.html. A share publishes a single page, so there is no second page for it to reach; it now opens a new tab showing a "not found" instead of failing silently.

HTML and React shares are full-screen by default: the page you publish IS the whole page, with no filename heading or frame; uncheck Full-screen (or pass fullBleed:false from a script) if you want the framed reading view instead. Other kinds (Markdown, text, code, PDF) ignore it and keep the readable column, and an image stays framed unless you turn Full-screen on.

On a phone these always show whole, never cut off: a wide desktop-style design is automatically scaled down to fit and centred (pinch-to-zoom for detail), so nothing gets stranded off the side: you don't have to make the design mobile-friendly yourself.

Background (only with Full-screen) is the colour behind the content. Leave it blank and Yardmaster picks one for you so it never looks jarring: an image gets a soft blurred version of itself behind it, and a web page gets a neutral that matches light/dark mode. Or type an exact colour (e.g. #0b0e14).

Readers can flip a share between light and dark with the toggle (or the tttt key). For an HTML or React share, Yardmaster hands that choice to your page, live, without a reload, as three signals. Your page decides what to do with them: Yardmaster never restyles your content for you.

• data-theme on your <html>: "light" or "dark". Style against it with [data-theme="dark"] body { ... }.

• prefers-color-scheme: inside your page this media query answers the reader's choice, not just their device setting, so a page that already has @media (prefers-color-scheme: dark) { ... } follows the toggle with no changes at all. This one is in place before the first paint.

• Ready-made colours: --share-bg, --share-surface, --share-text, --share-text-muted, --share-border, --share-accent, plus --share-theme (the theme name). Always give a fallback, for example color: var(--share-text, #111418), so the page still looks right when opened on its own.

It works on full-screen and framed shares alike and reaches shares you have already published (nothing to re-publish). On a share you locked to Light or Dark there is no toggle; there prefers-color-scheme carries your locked choice, while data-theme and the colours are not sent, so a page that styles with the media query looks right either way.

data-theme and the colours arrive a moment after your page starts, so for a page that must never flash the wrong theme, lean on prefers-color-scheme. Kit Shares handle their own theming and are unaffected.