A LangGraph thread stream can trace to the wrong LangSmith project

A LangGraph JavaScript protocol report says a thread-streamed run can execute normally while its trace lands in the deployment's default LangSmith project, despite the client requesting another project. The client sends langsmith_tracer; the protocol path reportedly drops it before building run configuration. A green run can therefore leave the team looking in the wrong place for incident evidence.

Diagnose the boundary

Start a test run with a unique identifier through the same thread protocol used in production. Search both the requested and default LangSmith projects for the trace, then compare the routing fields recorded at client and server boundaries. The issue identifies run.start over the thread command or WebSocket path on @langchain/langgraph-api 1.7.0; legacy and embedded run paths are described as handling the field differently. Do not extrapolate the report to every SDK call.

Decide the next safe change

If project separation is operationally important, test trace placement as part of release validation and record the observed destination. Until a fix is verified, route affected monitoring to the project where traces actually land or use a proven run path. Review access to the default project if traces can contain sensitive prompts or tool output. Confirm the fix with an end-to-end thread-streamed run; a client-only unit test can pass while the server silently drops the option.

Evidence boundary

Issue targets @langchain/langgraph-api 1.7.0 protocol run.start. It traces the dropped langsmith_tracer option in code; the reported defect is silent trace routing, not failed agent execution. A fix PR or released package was not verified.

Adovo’s view

Observability is useful only when an operator can find the evidence. A silent trace routing error creates a blind spot even when the agent succeeds. Treat destination and access checks as part of the run contract, not as dashboard housekeeping.