Why did my skill's output never reach the user?

Do not rely on writing a file to a directory as the act of delivering it.

Measured

In one lane the workspace location is itself the delivery channel and writing there is enough. In the other it delivers nothing: the file exists only inside a session filesystem that is discarded when the session ends, and the user never sees it. A skill written against the first behaviour loses its deliverables silently in the second — no error, no warning, just nothing.

Write the deliverable to a stated path, then present it with whichever delivery tool the session offers; if none exists, state the path and stop.

From binary Can change without a version bump

This is the pattern Anthropic's own bundled skill-authoring guidance uses, phrased as a capability check rather than a fixed tool name. Check what is available at the moment of use — the tool that presents files differs between lanes — and degrade to naming the path rather than failing. Do not hardcode one tool name and assume it exists.

Caveat: Which delivery tools exist in a session is served at spawn time and has changed across releases; the capability check is what makes this durable, not the tool names.

State the path of what you produced even when a delivery tool worked.

Inference

It costs one sentence and it is the only part of your output that survives every lane, every tool-surface change, and a user reading a transcript later. If delivery silently failed, the stated path is the difference between a recoverable result and a lost one.

Caveat: Reasoned from the lane split rather than measured; the cost is one sentence either way.

Never call a tool that writes to the user's own disk from inside a skill.

From binary

Committing files onto the user's machine is infrastructure the agent and the user negotiate through folder-connection consent, not something a skill should reach for. No first-party skill names such a tool. Present the file and let the delivery path be decided outside your skill.

Do not hand-copy files into the outputs location before presenting them.

From binary Can change without a version bump

The tool that presents files to the user copies what you give it out of the scratch space for you. Copying first and then presenting the copy produces duplicates and obscures which file is the deliverable.

Caveat: Behaviour of the presenting tool is served per session; check that it exists before relying on it.

Assume the session filesystem does not outlive the session.

Measured

On the remote lane the filesystem is discarded at session end. On the local lane undelivered files are hidden from the user rather than destroyed, and can in principle be surfaced on a later turn — but a skill should not depend on that difference. Deliver within the turn that produces the file.

Assume your skill may run in either of two lanes, and never assume which one.

Measured Can change without a version bump

Cowork sessions run either on the user's own machine or on remote infrastructure. The lanes differ in where the filesystem lives, whether it survives the session, and how a file reaches the user. Which lane a session uses depends on how it was created and on account configuration, neither of which a skill can control.

Caveat: Lane availability is rolled out per account, so two users running the same skill can be in different lanes.