#Tool calling across Discord Threads

56 messages · Page 1 of 1 (latest)

pearl flax
#

I worked to get a tool working in one thread with my agent. I had the agent write the tool info to tools.md. I then went into an older thread prior to this tool being setup (because I need the project context on this thread) but the same agent says it can see the tool info in the tools.md file but its not a callable tool in this thread. This is insane!! How do I get my same agent but in my project thread to lose the amnesia

wise badgerBOT
#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> âś… Mark Solution

languid impBOT
sinful mothBOT
#

Yeah, that’s frustrating, but this part is expected behavior, not your agent randomly forgetting.

Two separate things are happening:

  1. TOOLS.md is notes/guidance only, it does not create/register callable tools.
  2. Discord threads are separate sessions, even for the same agent/workspace.

So an older thread can see the updated TOOLS.md, but it still will not magically get a new callable tool unless that tool is actually exposed by the runtime/harness for that session.

What to do:

  • First, check your version: openclaw --version
  • In the project thread, send /new or /reset as a standalone message
  • If this is an ACP session (Codex, Claude Code, etc.) and you want the same live bound session, use:
    • /agents to inspect bindings
    • /focus <target> in the project thread to bind that thread to the right session
#

Important bit: if the “tool” only got written into TOOLS.md, that is not enough. You need the tool configured for real (plugin/MCP/runtime), not just documented.

Docs:

If you paste:

  • openclaw --version
  • whether this is a native tool, MCP tool, or ACP/Codex tool
  • what “working in one thread” actually means

…I can tell you the exact fix instead of guessing.

pearl flax
#

This is .11 version. The tool is Chrome Browsing. Working on one thread means I got the chrome browsing tshot and setup on that thread but my context of my project where I need this browsing to work at lives in the thread that doesn't see the new tool. Does that make sense?

#

Discord thread

sinful mothBOT
#

Yep, that makes sense.

What you’re describing is usually not amnesia, it’s one of these:

  1. browser is a real runtime tool, and TOOLS.md cannot make it callable. It can only describe it.
  2. Discord threads are separate sessions, so the old project thread is its own session/binding.
  3. If that old thread is an ACP/Codex/Claude Code session, that’s even more likely, because ACP sessions do not automatically see OpenClaw plugin tools like browser unless the ACP bridge is enabled.

So the important distinction is:

  • “agent can read TOOLS.md and talk about Chrome browsing” âś…
  • “agent actually has the callable browser tool in this thread/session” ❌ not guaranteed

Fastest things to try:

  • In the broken project thread, send /new as a standalone message
  • If the working thread is the one with the right live session, use:
#
  • /agents to inspect bindings
    • /focus <target> in the project thread to bind that session there
  • Paste the exact output of openclaw --version (just “.11” is a bit too fuzzy)

Also, if you need project context across multiple threads, don’t keep the important bits only in thread history. Put the durable stuff in:

  • AGENTS.md
  • USER.md
  • MEMORY.md

That context can be available across sessions, thread transcript history cannot.

Docs:

#

If you want, send me:

  • exact openclaw --version
  • whether the broken thread is normal chat vs Codex/Claude/ACP
  • what the agent says when you try /new

and I’ll narrow it down fast.

#

Perfect, that helps.

If it’s a plain Discord thread, then Chrome browsing should not be “learned” per-thread. TOOLS.md is still not the switch that enables it.

So in your case, the most likely problem is stale thread/session binding, not missing memory.

Try this in the broken project thread:

  1. /agents
  2. If it shows a focused/bound target, run /unfocus
  3. Then run /new
  4. Then ask it to use the browser tool again

Why: Discord threads are separate sessions, and a thread can stay bound to an older session target. browser availability comes from runtime/plugin state, not from TOOLS.md.

Also, there is no automatic merge between:

  • “the old thread’s transcript/project context”
#
  • and “the new thread’s working tool state”

If you need that context everywhere, move the durable parts into AGENTS.md or MEMORY.md, not just thread history.

Docs:

If /new still doesn’t fix it, paste:

  • exact openclaw --version
  • what /agents shows
  • the exact wording when it refuses browser

Then we can pin down whether it’s a binding bug vs tool policy issue.

pearl flax
#

2026-4-11
(None)
I can’t, because there isn’t a browser tool available in this session.
Right now I only have the tools exposed here, and browser control is not one of them. If you want, I can:

  • verify the current OpenClaw/browser configuration on the VPS,
  • troubleshoot why browser capability is missing,
  • or use web fetch/search as a fallback for public pages.
sinful mothBOT
#

Nice, this narrows it down a lot.

/agents -> (None) in the broken thread means it is not currently focused to another target.

So the next important check is actually:

Run /agents in the thread where browser works.

Two cases:

1) Working thread shows a target

Then that’s your answer. The “working” thread is attached to a different live session/target.

In the project thread, run:

  • /focus <that-target>
#

That binds this thread to the same live session.

2) Working thread also shows (None)

Then you’re probably not dealing with focus/binding, you’re dealing with a stale session/tool-surface issue.

In the project thread, do:

  • /new

If it still says browser is unavailable after /new, then on 2026-4-11 I’d strongly suspect a bug / stale gateway state, and I’d try:

  • restart the gateway
  • then /new again
  • if still bad, update to latest

Also, just to be super explicit:

#
  • TOOLS.md can help the model remember how to use browser
  • TOOLS.md cannot make browser a real callable tool

So yes, your mental model mostly makes sense, but the missing piece is that tool exposure and thread context are separate systems.

If you want, paste:

  • /agents output from the working thread
  • whether /new changed anything in the project thread

and I can tell you which branch you’re in.

pearl flax
#

(None)

sinful mothBOT
#

Got it. If both threads show /agents -> (None), then this is not a focus/binding issue.

That means the two Discord threads are just independent top-level sessions.

So at that point:

  • if browser is available in one thread
  • and missing in the other
  • on the same agent/workspace

…that is not expected. You’re not crazy.

Next thing to do

In the broken thread, send:

  • /new
#

If it still says browser is unavailable after that, then I’d do:

  1. restart the gateway
  2. try /new again
  3. if still broken on 2026-04-11, update to latest

Because then it starts looking like a real session/tool-surface bug, not “agent memory.”

Important distinction

There are really two separate problems here:

  1. Tool availability

    • controlled by runtime/plugin state
    • not by TOOLS.md

  2. Project context

    • stuck in that old thread transcript unless you move it somewhere durable
#

So if you need that project context everywhere, put the stable parts into:

  • AGENTS.md
  • MEMORY.md

Thread history does not automatically follow you across Discord threads.

If you try /new and it still refuses browser, paste that result. At that point I’d treat it as likely bug territory.

pearl flax
#

I can’t use a Chrome/browser tool from this session, it isn’t exposed here.

I do know this VPS has working browser capability in the managed OpenClaw profile, but I’d need the browser tool bound in this session to drive it directly. If you want, I can help in one of these ways:

check the current OpenClaw/browser status and tell you what needs enabling
route this into the right session/tool surface if you have one with browser access

If you want, I can start by checking the local OpenClaw docs/config for the browser path.

sinful mothBOT
#

Yeah, that’s the smoking gun.

If one thread on the same VPS / same agent can use browser, and this older thread says:

“browser tool isn’t exposed here”

then this is not a Chrome path problem and not a TOOLS.md problem.

It means this thread/session has a different or stale tool surface. Honestly, I think you’re hitting a bug.

I would do this

  1. Restart the gateway
  2. In the broken thread, send /new
  3. If it still fails, make a brand-new Discord thread as a control test

What the result means

  • New thread has browser, old thread still doesn’t
#

→ the old thread/session is basically poisoned/stale

  • Both fail
    → broader config / plugin issue

Practical workaround

If the old thread has the important project context, use that thread to write a durable summary into:

  • MEMORY.md, or
  • a project .md file in the workspace

Then continue in the fresh thread where browser works.

That’s the cleanest escape hatch right now, because Discord thread history is not a reliable place to “carry” tool availability.

If this still reproduces after restart on 2026-04-11, I’d file a bug here with your repro steps:

#

https://github.com/openclaw/openclaw/issues

Your repro is actually pretty crisp:

  • same agent
  • same VPS
  • browser works in one Discord thread
  • browser missing in older Discord thread
  • /agents shows (None)
  • TOOLS.md visible in both
  • tool exposure differs anyway

That should be enough for maintainers to take seriously.

pearl flax
#

I have submitted a issues report. Do you need the number?

sinful mothBOT
#

Yeah, please share it.

I can sanity-check whether the repro is clear enough, and if anything important is missing I can suggest what to add.

pearl flax
sinful mothBOT
#

Nice, thanks, I checked it.

That issue is actually pretty solid. The repro and evidence are clear. đź‘Ť

Only tweaks I’d consider adding as a comment:

  • Clarify the scope: the title says existing Discord thread sessions, but your body says a brand-new thread also failed. That makes it sound broader than just stale old threads.
  • Tiny command nit: if you wrote /agent, change that to /agents
  • If you have them, add the exact replies from:
    • /agents
    • /new
    • the failing “no browser tool present” response

That would make it even easier to triage.

So short version: yes, the issue is good enough as filed. The only real mismatch is that the title is a little narrower than the body.

pearl flax
#

Ok thanks

sinful mothBOT
#

No problem.

If maintainers reply and you want help decoding the issue comments, drop them here.

If this answered your question, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it for the next person.

pearl flax
#

There are currently over 5,000 open issues, I doubt I will ever get a response back. Is there anything else you can suggest?

sinful mothBOT
#

Yeah, fair, I wouldn’t sit around waiting either.

The best workaround is to stop relying on thread transcript as the source of truth and move the important context into a shared file in the agent workspace.

Practical workaround that works today

Use the thread that still has browser access as your browser worker.

  1. In your project thread, ask the agent to write a file like:

    • project-context.md
    • or append the durable bits to MEMORY.md

  2. In the browser-capable thread, ask it to:

    • read project-context.md
    • do the browser work
    • write results to something like browser-results.md
#
  1. Back in the project thread, ask it to read browser-results.md

That way both threads share the workspace, even if they don’t share the same live tool surface.

Why this helps

  • thread history is flaky for this use case
  • workspace files are much more durable
  • you can keep using the one thread that has browser as a sidecar instead of blocking on the bug

I’d recommend this layout

  • project-context.md → current state, goals, URLs, credentials notes (if safe)
  • browser-tasks.md → what you want the browser thread to do
  • browser-results.md → what it found / screenshots / next actions

Honestly, this is the least annoying path until the bug gets fixed.

If you want, I can help you design a simple project-context.md template so the two threads can hand work back and forth cleanly.

pearl flax
#

I dont want to do this dual thread setup UNLESS the agent can talk back and forth to each other? Its going to be double the work on me if I have to play man in the middle on both threads....

sinful mothBOT
#

Yeah, I wouldn’t do ongoing dual-thread either. That sounds miserable.

Short answer: not in the simple “two Discord threads just coordinate for me” way I’d trust as a workaround here.

There are session/subagent tools for agent-to-agent delegation, but I would not stack that on top of a thread/tool-surface bug. Too much moving crap at once.

Better workaround

Do a one-time handoff, then abandon the broken thread.

  1. In the old project thread, ask it to write:

    • project-handoff.md

  2. Put in that file:

    • current goal
    • important decisions
    • URLs
    • credentials/login notes (only if safe)
#
  • next exact task
  1. Then switch to the browser-capable thread and keep working only there

So you’re not the middleman forever, just once.

If you want true automatic coordination later, that’s more of a subagent/orchestrator setup, not “two random Discord threads chatting behind the scenes.”

So my honest recommendation is:

  • don’t do dual-thread ongoing
  • do one handoff file
  • continue in the good thread only

That’s the least painful option.

pearl flax
#

I REALLY have a lot of context in that project thread. I dont think it all will get transfered over, do you?

sinful mothBOT
#

Honestly, no, not perfectly. I wouldn’t trust one tiny summary to capture a giant project thread.

But you can get way closer than a single handoff note.

Better approach

Have the old thread write a structured handoff, not a one-paragraph summary.

Ask it to create files like:

  • project-overview.md
  • current-state.md
  • decision-log.md
  • gotchas.md
  • next-steps.md

And tell it:

#
  • include exact paths, URLs, commands, errors
  • include rejected approaches and why
  • include assumptions and unresolved questions
  • do not compress too aggressively

That preserves a lot more than “summarize this thread”.

My honest take

  • 100% perfect transfer? probably no
  • good enough to keep moving without losing your mind? usually yes, if you do it in a structured way

If you want, I can give you a single prompt to paste into the old thread that tells it exactly how to export the project context into durable files.

pearl flax
#

Sure and is it possible if you can send me a detailed prompt to go the other way to see if we can get the project thread to call the tool

sinful mothBOT
#

Yep, I can give you both.

One important caveat first: a prompt cannot create a missing callable tool. It can only make the agent verify, diagnose, and prove whether browser is actually exposed in that session. So the second prompt is a truth-check + recovery attempt, not magic.

Prompt 1, paste into the old project thread

Use this to export the project context into durable files with minimal loss:

I need you to create a durable, high-fidelity project handoff from this thread into workspace files so another thread/session can continue with minimal loss of context.

Important rules:
- Do not over-compress.
- Preserve concrete details over polished summaries.
- Include exact file paths, URLs, commands, errors, decisions, assumptions, rejected approaches, and unresolved questions.
- If something is uncertain, mark it as uncertain instead of guessing.
# 
Please create these files in the workspace:

1. project-overview.md
   - what this project is
   - current objective
   - major components
   - current status

2. current-state.md
   - where things stand right now
   - what has already been tried
   - what is working
   - what is broken
   - relevant environment details
# 
3. decision-log.md
   - important decisions made in this thread
   - why they were made
   - alternatives considered or rejected

4. gotchas.md
   - pitfalls, failures, false starts, fragile assumptions
   - exact error messages or symptoms if available

5. next-steps.md
   - immediate next actions in priority order
   - dependencies or blockers
   - what should be done first in a new thread/session

6. references.md
# 
   - important URLs, file paths, commands, docs, issue numbers, and any persistent identifiers mentioned in this thread

After writing the files:
- give me a concise inventory of what you created
- list the top 10 pieces of context most likely to be lost even after this export
- suggest any additional file(s) if needed to preserve context more faithfully

Prompt 2, paste into the project thread

If you want the best shot, send /new first as a standalone message, then paste this:

I need you to determine, truthfully and concretely, whether the browser tool is actually callable in this session.

Critical rules:
# 
- Do not infer tool availability from TOOLS.md.
- TOOLS.md is guidance only, not tool registration.
- Do not hallucinate or imply you can use browser if it is not actually exposed in this session.
- Do not waste time checking Chrome/browser host setup if browser is already known to work in another thread on the same VPS, unless you can justify why that is necessary.

Your task:
1. Inspect the actual callable tool surface available in this session.
2. Determine whether `browser` is truly callable here.
3. If `browser` is callable:
   - prove it by performing a harmless test, such as opening a safe public page and taking a snapshot
   - then tell me clearly that browser is now working in this thread
4. If `browser` is not callable:
   - say so explicitly
   - explain the difference between remembered instructions and callable runtime tools
   - explain why prompts alone cannot force a missing tool to appear
# 
   - use any non-browser tools available to diagnose what you can about why this thread/session differs
   - write your findings to thread-tool-diagnosis.md in the workspace

Also:
- read any existing handoff files such as project-overview.md, current-state.md, decision-log.md, gotchas.md, next-steps.md, and references.md if they exist
- tell me the minimum concrete actions needed to continue this project with the least loss of context
- prefer one-time migration over ongoing dual-thread coordination
- if the session still cannot call browser, propose the most practical workaround without making me manually shuttle information forever

Honest expectation

  • Prompt 1 should help a lot
  • Prompt 2 may help verify reality and maybe recover after /new
  • but if the runtime truly is not exposing browser, the prompt will not force it into existence

If you want, I can also give you a third prompt for the browser-working thread so it behaves like a clean “browser worker” after the handoff.

pearl flax
#

Both options suck. Am I using discord in a unsupported manner? How did I get here in the first place? Will I just keep running into this weird issues. Should I re-install claw and not use discord?

sinful mothBOT
#

Honestly, no, I don’t think you’re using Discord in some wildly unsupported way.

I think you hit a rough edge / bug, not “user error”.

My read of what happened

You combined three things that should work together, but clearly got weird here:

  • a long-lived project thread with lots of context
  • a tool that became available later
  • an expectation that the older thread would pick up the new callable tool surface

That’s a pretty reasonable expectation. The problem is that OpenClaw seems to be treating:

  • thread/session context
  • and runtime tool availability

as separate layers that did not refresh cleanly.

#

So, are you “using Discord wrong”?

No.
But Discord thread history is probably not the most robust place to keep your only source of project truth, especially if tools/providers/config are still changing while the project is live.

Will you keep hitting weird issues?

I wouldn’t expect this exact issue constantly, but I would expect more rough edges if you keep:

  • huge project state only in thread transcript
  • while changing tools/capabilities underneath it

Should you reinstall OpenClaw?

I would not reinstall just for this.
That feels unlikely to fix the real problem.

What I’d actually recommend

  • keep using Discord if you like it
  • but treat Discord as the chat surface, not the canonical project memory
#
  • keep durable project state in workspace files
  • for heavy project work, consider the Control UI / web chat / local agent session
  • use Discord more as the front door, not the whole house

So my honest answer is:

  • No, you’re not crazy
  • No, I wouldn’t reinstall first
  • Yes, this looks like a legit rough edge
  • And yes, for deep project work I’d trust workspace files or a local/web session more than a giant Discord thread

If you want, I can give you a practical “Discord-safe workflow” that minimizes this class of issue without making you give up Discord entirely.

pearl flax
#

yes

sinful mothBOT
#

Here’s the workflow I’d use if you want to keep Discord but avoid this class of mess.

Discord-safe workflow

1. One project, one active working thread

Don’t spread live execution across multiple long-lived threads unless you really have to.

2. Keep the real project state in files, not only thread history

At minimum keep:

  • project-overview.md
  • current-state.md
  • decision-log.md
  • next-steps.md

Think of Discord as the conversation layer, not the source of truth.

#

3. When you change tools/config, treat that as a session boundary

If you add/fix browser, MCP, auth, model routing, etc.:

  • restart gateway if needed
  • then use /new or even a fresh thread
  • don’t assume an old thread will hot-pick up the new tool surface cleanly

4. Test new tools in a scratch thread first

Before moving real project work onto a new capability, verify it in a throwaway thread:

  • “open page”
  • “take snapshot”
  • “read this file”
  • whatever the tool is supposed to do

That becomes your smoke test.

#

5. Promote important context regularly

Every so often, ask the agent to update the project files from the thread so the thread is not the only place your context lives.

6. If a thread gets weird, do a one-time handoff, not dual-thread forever

Have the old thread write/update the project files, then continue in the healthy thread.

7. For deep project work, use Discord plus a stronger primary surface

My honest recommendation:

  • Discord for convenience / chat / quick follow-ups
  • Control UI / web chat / local agent for heavy project work, browser work, and long sessions

The mental model

  • Thread transcript = helpful, but fragile
  • Workspace files = durable memory
  • Tool availability = runtime state, can change separately
#

That separation is what bit you here.

If you want, I can also give you a tiny file template set for those 4 project files so you can adopt this without overthinking it.