Tool Works in DM but Fails in Server?

Fast reality check

Same agent identity does not mean same runtime context. DM and server threads can have different:

• tool access policy
• channel restrictions
• session history and instruction state

2-minute diagnosis flow

1. Prove the exact error text.
   Prompt: Run the same tool call and paste the exact error text, no summary.
2. Run a tiny canary in both places.
   Use a minimal test task (like one-line file write or one search query) in DM and then in the server thread.
3. Check destination context.
   Prompt: State current session/thread context and active policy limits before retrying.
4. Retest in a fresh thread.
   Start a new clean thread and rerun only the canary task.

If DM succeeds and server fails on the same canary, you’ve isolated a channel/session policy issue.

High-friction mistakes

• Assuming DM success proves server config: they are separate contexts.
• Testing in noisy old threads: stale instructions can silently constrain tool use.
• Skipping exact error capture: “it failed” is not enough to diagnose quickly.
• Changing many variables at once: makes root cause impossible to isolate.

Copy/paste recovery prompt

Before doing any work, show current context (surface + thread/session) and any tool/policy limits. Then run this canary task exactly once and return raw output only: create file canary-tool-context.txt with one line "tool context canary" and confirm absolute path. If blocked, return exact error text and where it was blocked.

When to escalate to #help

Escalate with this packet:

• Timestamp + timezone
• DM canary result vs server canary result
• Exact server channel/thread where failure occurs
• Exact error text (verbatim)

Without side-by-side canary proof, support has to guess between policy, permissions, and runtime state.