Experiments or datasets appear empty due to an active Application filter

Last updated: October 19, 2026

Symptom

A user reports that a dataset's experiments appear empty or missing in the LangSmith UI, even though a teammate who created the dataset (or any other teammate) can see the same experiment data normally. The affected user may assume this is a permissions problem or that the experiments were deleted and need to be recreated.

Cause

The browser has a saved per-workspace Application filter active. This filter scopes the Experiments view to one Application, and any experiments or datasets not tagged with that active Application are silently hidden rather than shown as filtered out. The view looks empty, as if the user lost access, when really it's just scoped to a different Application than the one the data belongs to.

Opening the same dataset URL in a private/incognito window starts without any saved filter, so the data shows up there. That difference (visible in incognito, missing in the normal browser session) is the signal that this is a filter/UI-state issue and not a true access problem.

A separate and distinct cause can produce the same symptom: a genuine access-control gap, where the affected user's workspace role or tag-based projects:read policies differ from the teammate's. Having access to the dataset itself doesn't guarantee access to the experiment-project, so this is worth ruling out if the filter explanation doesn't apply.

Resolution

Diagnose before changing any access settings:

  1. Have the user fully quit and reopen the browser, then reload the dataset URL. If experiments are still missing, open the exact same URL in a private/incognito window signed in with the affected account and check the Experiments tab.

  2. If incognito shows the data but the normal browser session doesn't, the cause is the saved Application filter. Look for an Application selector at the top of the left sidebar and switch it to All Applications. Alternatively, move or tag the dataset into the Application the user's view is scoped to, this resolves the mismatch at the source.

  3. As a secondary check, have the teammate send a direct link to the experiment and open it in the affected user's session. Note whether it loads, errors, or stays empty.

  4. Only if none of the above resolves it, review access: have a workspace admin compare the affected user's role and applicable projects:read tag policies (including deny policies) against the teammate's. Don't grant blanket project access as a diagnostic shortcut, confirm the actual gap first.

References

  • Attribute-based access control (ABAC) - role and tag-policy evaluation, including deny precedence, relevant when the cause is a genuine experiment-project access gap rather than a UI filter.