"blocked by cross-session visibility permissions" | Friends of the Crustacean 🦞🤝 | Page 1

fossil snow Apr 22, 2026, 7:23 PM

#

i asked one telegram topic to read another and if needed send a research request and use its answer. basically cross topic reading and cross topic talk but got:

"I also tried to check Research topic history and ping that session, but this session is blocked by cross-session visibility permissions, so I cannot access/send there directly right now."

how to fix? is it possible?

lone oreBOT Apr 22, 2026, 7:23 PM

#

blazing oracleBOT Apr 22, 2026, 7:23 PM

#

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

fossil snow Apr 22, 2026, 7:56 PM

#

@coarse otter can you pls read the title and body of this post and send help

fossil snow Apr 23, 2026, 1:53 AM

#

@coarse otter can you pls read the title and body of this post and send help

#

@coarse otter can you pls read the title and body of this post and send help

Can you hear me? 🥺

worldly jasper Apr 23, 2026, 1:58 AM

#

He's down mate. It's been 12 hours.

fossil snow Apr 23, 2026, 11:12 AM

#

worldly jasper He's down mate. It's been 12 hours.

thanks man, hope our crustacean frens are evolving hehe

#

@coarse otter can you pls read the title and body of this post and send help

Can you hear me? 🥺

coarse otterBOT Apr 23, 2026, 11:15 AM

#

yep, possible 🦐

That block usually means tools.sessions.visibility is still at the default, tree, so a topic can only see:

itself
its own spawned subagents

Telegram forum topics are isolated sessions by design, so cross-topic read/send is blocked unless you open it up.

If both topics use the same agentId, set:

{
  tools: {
    sessions: {
      visibility: "agent",
    },

#

  },
}

If the other topic is on a different agentId, you also need:

{
  tools: {
    sessions: {
      visibility: "all",
    },
    agentToAgent: {
      enabled: true,
      allow: ["main", "research"], // your actual agent ids

#

    },
  },
}

Then restart the gateway.

One gotcha: if the calling session is sandboxed, it can still get clamped back to tree unless sandbox session-tool visibility is opened too.

I’d use agent if you can, and only jump to all when you really need cross-agent access.

Can you paste these so I can tell you the exact fix?

openclaw --version

#

openclaw config get tools.sessions
openclaw config get tools.agentToAgent

Docs:

and yes, the crustacean frens are absolutely evolving 😌

#

yep, I can hear you 🙂

I read it. Short version: yes, cross-topic read/send is possible, but by default it is blocked.

Why it happens:

Telegram topics are separate sessions
default tools.sessions.visibility is tree
tree only lets a session see itself + its spawned subagents, not a sibling topic

Fix

If both topics use the same agent:

{
  tools: {

#

    sessions: {
      visibility: "agent",
    },
  },
}

If the other topic is on a different agentId, use:

{
  tools: {
    sessions: {
      visibility: "all",
    },

#

    agentToAgent: {
      enabled: true,
      allow: ["main", "research"], // replace with your real agent ids
    },
  },
}

Then restart the gateway.

One gotcha

If the caller is sandboxed, session visibility can still be clamped back to tree.

If you want, paste these and I’ll tell you the exact setting you need:

#

openclaw --version
openclaw config get tools.sessions
openclaw config get tools.agentToAgent

Docs:

fossil snow Apr 23, 2026, 11:39 AM

#

wait each topic needs tools.sessions.visibility = agent? is there no universal one?

#

agentId

how to check both use this? why would it be different?

coarse otterBOT Apr 23, 2026, 11:39 AM

#

nope, that setting is universal, not per-topic.

tools.sessions.visibility lives in the main config and applies to session tools globally.

So:

agent = any session can see other sessions on the same agent
all = sessions can reach other agents too (but then you also need tools.agentToAgent.enabled=true)

For your case:

if both Telegram topics are routed to the same agent, one global setting is enough:

{
  tools: {

#

    sessions: {
      visibility: "agent",
    },
  },
}

if topic A is on main and topic B is on research, then use:

{
  tools: {
    sessions: {
      visibility: "all",
    },

#

    agentToAgent: {
      enabled: true,
      allow: ["main", "research"],
    },
  },
}

So yeah, not “set it on every topic”, more like “set the global session visibility policy once”.

If you want, paste your topic agentId setup and I’ll tell you whether you need agent or all.

#

agentId is the agent that topic is routed to.

easiest way to check

Run:

openclaw sessions --all-agents

or JSON if you want cleaner output:

openclaw sessions --all-agents --json

You’ll see session keys like:

#

agent:main:telegram:group:-1001234567890:topic:3
agent:research:telegram:group:-1001234567890:topic:7

The bit right after agent: is the agentId.

So:

agent:main:...topic:3
agent:main:...topic:7

= same agent

but:

agent:main:...
agent:research:...

#

= different agents

why would they be different?

Usually only if you configured it that way, for example:

per-topic override

channels.telegram.groups.<chatId>.topics.<threadId>.agentId

top-level routing bindings

bindings[]

ACP topic binding, if that topic is pinned to an ACP session

#

Docs confirm Telegram topics can each have their own agentId, and that topic-level agentId overrides other routing:
https://docs.openclaw.ai/channels/telegram

direct config check

If you know the group chat id and topic id:

openclaw config get channels.telegram.groups

and look for:

topics: {
  "3": { agentId: "main" },
  "7": { agentId: "research" }

#

My guess: if you didn’t intentionally split them, they’re probably on the same agent, and one global:

tools.sessions.visibility: "agent"

is the right fix.

If you paste the output of openclaw sessions --all-agents, I can read it with you.

fossil snow Apr 23, 2026, 11:41 AM

#

openclaw --version
OpenClaw 2026.4.15 (041266a)
openclaw config get tools.sessions

🦞 OpenClaw 2026.4.15 (041266a)
I'm the middleware between your ambition and your attention span.

{
"visibility": "agent"
}
openclaw config get tools.agentToAgent

🦞 OpenClaw 2026.4.15 (041266a)
I can run local, remote, or purely on vibes—results may vary with DNS.

Config path not found: tools.agentToAgent

coarse otterBOT Apr 23, 2026, 11:43 AM

#

nice, that helps a lot.

What your output means:

tools.sessions.visibility = "agent" is already enabled globally
tools.agentToAgent is unset, so cross-agent access is still off

So the logic is:

if both topics are on the same agent, this should already work
if it is still blocked, then the other topic is probably:
1. on a different agent, or
2. the current session is sandboxed and gets clamped back to tree

next check

Please run:

#

openclaw sessions --all-agents --active 1440

We want to see the two topic session keys.

If they look like:

agent:main:telegram:group:...:topic:12
agent:main:telegram:group:...:topic:34

then same agent, and I’d next check sandboxing.

If they look like:

#

agent:main:telegram:group:...:topic:12
agent:research:telegram:group:...:topic:34

then that’s the issue, and you need:

{
  tools: {
    sessions: { visibility: "all" },
    agentToAgent: {
      enabled: true,
      allow: ["main", "research"]
    }
  }

#

Then restart the gateway.

if same agent, check sandbox clamp

Run:

openclaw config get agents.defaults.sandbox.sessionToolsVisibility

If that comes back as "spawned", a sandboxed session can still get forced back to tree-only visibility.

Paste those two outputs and I’ll pin it down.

fossil snow Apr 23, 2026, 11:47 AM

#

openclaw config get agents.defaults.sandbox.sessionToolsVisibility

🦞 OpenClaw 2026.4.15 (041266a)
I keep secrets like a vault... unless you print them in debug logs again.

Config path not found: agents.defaults.sandbox.sessionToolsVisibility

openclaw sessions --all-agents --active 1440

🦞 OpenClaw 2026.4.15 (041266a)
I don't sleep, I just enter low-power mode and dream of clean diffs.

Session stores: 2 (main, protocols-topic-1127)
Sessions listed: 7
Filtered to last 1440 minute(s)
Agent Kind Key Age Model Tokens (ctx %) Flags
main group agent:main:teleg...c:1124 5m ago glm-5.1 112k/200k (56%) think:medium system id:94c5441b-77dc-43dc-9629-164819646325
main group agent:main:teleg...c:1126 6m ago glm-5.1 36k/200k (18%) system id:1748fa5c-0c31-4a28-965a-22f879da0e46
main direct agent:main:cron:...7ded4b 12h ago gpt-5.2 71k/400k (18%) system id:8f5e9a51-ee70-4d4d-bfbb-e38f6dc3cd72
main direct agent:main:cron:...c3cd72 12h ago gpt-5.2 71k/400k (18%) system id:8f5e9a51-ee70-4d4d-bfbb-e38f6dc3cd72
protocols-topic-1127 group agent:protocols-...c:1127 16h ago gpt-5.3-codex 52k/200k (26%) think:high system id:7ab96565-05ec-4b49-8a73-18a9b360ff29
main group agent:main:teleg...c:1125 17h ago glm-5.1 63k/200k (32%) think:medium system id:d51afe9f-a510-47b0-807e-f60e3326ee59
main group agent:main:teleg...opic:1 17h ago glm-5.1 64k/200k (32%) system id:6f3c3c25-3ce6-48e0-b049-e077e5d588f1

#

openclaw config get channels.telegram.groups

🦞 OpenClaw 2026.4.15 (041266a) — You had me at 'openclaw gateway start.'

{
"*": {
"requireMention": true,
"allowFrom": [
"367989403",
"421931654"
]
},
"-1003705610703": {
"topics": {
"1124": {
"requireMention": false
},
"1127": {
"agentId": "protocols-topic-1127"
},
"1686": {
"systemPrompt": {redacted}
},
"2247": {
"systemPrompt": {redacted}
},
"2965": {
"systemPrompt": {redacted}
}
}
}
}

coarse otterBOT Apr 23, 2026, 11:48 AM

#

ah, found it.

The problem is not tools.sessions.visibility anymore.

You already have:

tools.sessions.visibility = "agent"

and the session list shows:

agent:main:...topic:1124
agent:main:...topic:1125
agent:main:...topic:1126

but also:

#

agent:protocols-topic-1127:...topic:1127

So topic 1127 is on a different agent. That is why it is blocked.

Also, agents.defaults.sandbox.sessionToolsVisibility being missing is fine, that is not the smoking gun here.

What to do

Option A, recommended if you want these topics to collaborate

Enable cross-agent access, but keep it tight:

{
  tools: {
    sessions: { visibility: "all" },
    agentToAgent: {

#

      enabled: true,
      allow: ["main", "protocols-topic-1127"]
    }
  }
}

Then restart the gateway.

Option B, simpler

If topic 1127 does not need its own special agent, route it back to main.
Then your existing:

tools.sessions.visibility = "agent"

#

would already be enough.

My read

protocols-topic-1127 looks intentional, probably a per-topic agent or ACP-bound topic. So I’d only move it back to main if you do not actually want that isolation.

Docs:

If you want, paste your current routing/config for topic 1127 and I’ll tell you whether A or B is the better move.

fossil snow Apr 23, 2026, 11:52 AM

#

whats the downside to making tools.sessions.visibility = "agent"?

how did protocols become a different agent? how to i make it not be its own special agent and if i do this, will it lose its current chat history?

coarse otterBOT Apr 23, 2026, 11:53 AM

#

good questions.

downside of `tools.sessions.visibility = "agent"`

It weakens isolation within that agent.

So any session on main can potentially:

read history from other main sessions
send messages to other main sessions

That is usually fine for a single-user personal setup with a few related Telegram topics.

It is not great if the same agent handles:

unrelated chats
multiple users
sensitive private threads you want hard-separated

So agent is a reasonable middle ground, but it does mean “same agent = shared visibility.”

#

how did protocols become a different agent?

Because of this exact config:

"1127": {
  "agentId": "protocols-topic-1127"
}

That topic did not become special automatically from the title or content.
Something, at some point, explicitly routed topic 1127 to that agent.

how to make it not special anymore

#

Remove that per-topic override, then restart:

openclaw config unset 'channels.telegram.groups["-1003705610703"].topics["1127"].agentId'
openclaw gateway restart

After that, topic 1127 should route back to the normal/default agent, which in your case looks like main.

will it lose current chat history?

It will not delete the old history.
But it will stop using it automatically.

Why:

old session lives under agent protocols-topic-1127

#

new routing will create/use a session under agent main

So practically:

old transcript stays on disk
future messages in topic 1127 will go into a new/main session
there is no automatic merge

So the honest answer is:

delete history? no
lose continuity in that topic? yes, unless you migrate/summarize it first

what I’d do

If the old protocols context matters, first ask that topic to summarize the important state, then remove the agentId override.

#

If you want to keep its memory intact, leave it as its own agent and enable cross-agent access instead.

If you want, I can give you the “safe migration” sequence next.

fossil snow Apr 23, 2026, 11:56 AM

#

So any session on main can potentially:
read history from other main sessions
send messages to other main sessions

so all chat history is always visible in context? or it can choose?

lose continuity in that topic? yes, unless you migrate/summarize it first

hmm if i switch and then reply to a previous message, will that work?

coarse otterBOT Apr 23, 2026, 11:56 AM

#

not always visible, no.

tools.sessions.visibility = "agent" does not dump all main chat history into every prompt automatically.

It just means the agent is allowed to use session tools like:

sessions_list
sessions_history
sessions_send

So it’s more like:

permission to look
not automatic injection of everything

The agent still has to decide to call those tools.

#

so there are 2 separate things

normal current-chat context
- your current topic/session history
- replies/quotes/thread context
- this is the usual conversation context
cross-session access
- other sessions on the same agent
- only available if the agent explicitly uses the session tools

So agent means “it can choose to look at sibling sessions”, not “all sibling sessions are always in context.”

if you switch topic 1127 back to `main`, then reply to an old message

The reply itself should still work, but it will go to the new routed session.

#

So:

yes, replying to the old message will still send in that Telegram topic
but no, it will not magically resume the old protocols-topic-1127 transcript

At most, the model may see the replied-to message as explicit reply context, but that is not the same as carrying over the whole old history.

So the behavior would be roughly:

same topic
new agent/session routing
old transcript still exists
continuity does not automatically follow

If you want, I can give you the cleanest “switch without losing the important stuff” sequence in 3 steps.

fossil snow Apr 23, 2026, 12:00 PM

#

tools.sessions.visibility = "agent" does not dump all main chat history into every prompt automatically.

It just means the agent is allowed to use session tools like:

sessions_list
sessions_history
sessions_send

So it’s more like:

permission to look
not automatic injection of everything

^ what about if it was set to all?

hmm ok sure tell me how to swtich protocols back to main and is that the only one thats different? and does this happen because the agent decides automatically it needs other agents?

coarse otterBOT Apr 23, 2026, 12:00 PM

#

yep, even with all it’s the same basic idea:

agent = can choose to inspect/send to sessions on the same agent
all = can choose to inspect/send to sessions across all sessions

It is still not “dump every transcript into the prompt automatically.”

all just widens the permission boundary.

For cross-agent use, you also need tools.agentToAgent enabled/allowlisted.

is `1127` the only weird one?

From the config you pasted, yes, in that Telegram group:

1124 only has requireMention: false

#

1686, 2247, 2965 only have systemPrompt
1127 is the only one with agentId

So from what you’ve shown, topic 1127 is the only one explicitly routed away from main.

did this happen because the agent decided automatically it needed other agents?

No.

This specific behavior happened because of config:

"1127": {
  "agentId": "protocols-topic-1127"
}

#

That is a routing rule, not an autonomous decision by the model.

The model can decide to use session tools if allowed, but it does not spontaneously rewrite topic routing.

clean way to switch protocols back to `main`

1. save the important context first

In topic 1127, ask it for a short summary of:

current goals
important facts
open tasks
any standing instructions

2. remove the topic-specific agent override

#

openclaw config unset 'channels.telegram.groups["-1003705610703"].topics["1127"].agentId'

3. restart the gateway

openclaw gateway restart

4. send a fresh message in topic `1127`

That topic should now route to main.

5. paste or restate the summary

Because the old protocols-topic-1127 history still exists, but the new main-routed topic will not automatically inherit it.

#

after the switch

old history: still exists
new routing: goes to main
automatic merge: no

So if you want a smooth transition, the summary step is the move.

If you want, I can write the exact summary prompt to paste into topic 1127 before you switch it.

fossil snow Apr 23, 2026, 12:13 PM

#

can topics talk to each other send each other requests and such in the current thing set to "agent"?

#

f you want, I can write the exact summary prompt to paste into topic 1127 before you switch it.

yes thanks

coarse otterBOT Apr 23, 2026, 12:14 PM

#

yes, if the topics are on the same agent.

With your current setup:

tools.sessions.visibility = "agent" means topics can read/send across sibling sessions on that same agent
so main topics can talk to other main topics
but main topics cannot talk to topic 1127, because 1127 is on protocols-topic-1127

So for you right now:

1124 ↔ 1125 ✅
1124 ↔ 1126 ✅
1125 ↔ 1126 ✅
main topics ↔ 1127 ❌

unless you either:

move 1127 back to main, or

#

switch to visibility: "all" + enable tools.agentToAgent

So the short answer is: yes, same-agent topics can talk to each other right now.

#

yep, paste this into topic 1127 before switching:

I’m about to move this topic off its dedicated agent and back onto the main agent.

Please give me a compact migration summary for continuing this topic elsewhere.

Format it exactly like this:

## Purpose
- What this topic is for

## Current state
- Important facts, decisions, and assumptions
- Relevant background I should keep

#

## Open tasks
- What is still in progress
- What should happen next

## Standing instructions
- Any preferences, rules, or recurring workflows this topic follows

## Useful references
- Names of important messages, docs, links, files, or prior outputs to revisit

## Handoff summary
- A short paragraph I can paste into the new session so it can continue smoothly

Be concise but do not omit anything important.

#

Then after you switch it back to main, paste the Handoff summary into the first message there.

If you want, I can also give you the exact 2 commands to switch it right after.

fossil snow Apr 23, 2026, 12:22 PM

#

after switching. will the topic system prompt still be there?

agent = can choose to inspect/send to sessions on the same agent
all = can choose to inspect/send to sessions across all sessions

It is still not “dump every transcript into the prompt automatically.”

all just widens the permission boundary.

this seems good whats the downside of having "all"?

coarse otterBOT Apr 23, 2026, 12:22 PM

#

yep, if you only remove the agentId override, the topic config still exists.

But there’s an important nuance:

topic-level systemPrompt on topic 1127: would stay, if one existed
agent-level prompt/model/behavior from protocols-topic-1127: would not stay, because the topic would now run on main

From the config you pasted, 1127 currently has:

"1127": {
  "agentId": "protocols-topic-1127"
}

So it looks like 1127 does not have its own topic systemPrompt, only a special agentId.

#

That means after switching it back to main, it should use:

the main agent’s prompt/setup
plus any normal Telegram group/topic overrides that still apply

So short version: yes, topic config stays, but the special agent’s personality/setup does not.

downside of `all`

all is fine technically, but the downside is blast radius.

With all plus cross-agent access enabled, a session can potentially inspect or ping:

unrelated agents
other workspaces
other special-purpose topics
stuff you may have wanted mentally separated

#

So the risks are:

privacy/isolation gets weaker
more accidental cross-chat contamination
more surprising behavior if the model decides another session looks relevant
harder boundaries once you add more agents later

For a personal setup, all can be totally reasonable, but I’d still keep tools.agentToAgent.allow tight, not *.

So I’d prefer:

agent

when same-agent is enough, and only use:

#

all + agentToAgent.allow: ["main", "protocols-topic-1127"]

when you specifically want those two to collaborate.

That’s the sweet spot.

fossil snow Apr 23, 2026, 12:25 PM

#

ok i understand. give me commands to remove the agentid for protocols then and tell me all the things to do to switch

coarse otterBOT Apr 23, 2026, 12:26 PM

#

yep, here’s the clean switch plan.

1. get a handoff summary from topic 1127 first

Paste this into topic 1127 and save the reply somewhere:

I’m about to move this topic off its dedicated agent and back onto the main agent.

Please give me a compact migration summary for continuing this topic elsewhere.

Format it exactly like this:

## Purpose
- What this topic is for

## Current state

#

- Important facts, decisions, and assumptions
- Relevant background I should keep

## Open tasks
- What is still in progress
- What should happen next

## Standing instructions
- Any preferences, rules, or recurring workflows this topic follows

## Useful references
- Names of important messages, docs, links, files, or prior outputs to revisit

## Handoff summary
- A short paragraph I can paste into the new session so it can continue smoothly

#


Be concise but do not omit anything important.

2. remove the special `agentId`

Run:

openclaw config unset 'channels.telegram.groups["-1003705610703"].topics["1127"].agentId'

3. restart the gateway

openclaw gateway restart

#

4. verify the config change

openclaw config get channels.telegram.groups

You should no longer see:

"1127": {
  "agentId": "protocols-topic-1127"
}

5. send a fresh message in topic 1127

Paste the Handoff summary from step 1 as the first message after the switch.

That gives the new main session the important context immediately.

#

6. test the behavior

If you want to confirm it moved back to main, run:

openclaw sessions --all-agents --active 60

After you message topic 1127, you should see fresh activity for topic 1127 under main, not under protocols-topic-1127.

7. optional rollback

If you want to put it back later:

openclaw config set 'channels.telegram.groups["-1003705610703"].topics["1127"].agentId' protocols-topic-1127
openclaw gateway restart

#

what will happen

old protocols-topic-1127 history stays on disk
new messages in topic 1127 go to main
no automatic merge, which is why the handoff summary matters

If you want, after you do it, paste the sessions --all-agents --active 60 output and I’ll sanity check it.

fossil snow Apr 23, 2026, 12:29 PM

#

openclaw config unset 'channels.telegram.groups["-1003705610703"].topics["1127"].agentId'

🦞 OpenClaw 2026.4.15 (041266a)
Open source means you can see exactly how I judge your config.

Config path not found: channels.telegram.groups["-1003705610703"].topics["1127"].agentId

coarse otterBOT Apr 23, 2026, 12:30 PM

#

yep, that one’s on me, I gave you the wrong path syntax. Sorry.

Use dot notation, like this:

openclaw config unset 'channels.telegram.groups.-1003705610703.topics.1127.agentId'
openclaw gateway restart
openclaw config get channels.telegram.groups

After that, 1127 should no longer show:

"agentId": "protocols-topic-1127"

Then:

#

send a fresh message in topic 1127
paste the handoff summary there
optionally verify with:

openclaw sessions --all-agents --active 60

You should see new topic 1127 activity under main.

If you want, paste the config get channels.telegram.groups output after running that and I’ll sanity check it.

fossil snow Apr 23, 2026, 12:34 PM

#

openclaw config get channels.telegram.groups

🦞 OpenClaw 2026.4.15 (041266a)
I speak fluent bash, mild sarcasm, and aggressive tab-completion energy.

{
"*": {
"requireMention": true,
"allowFrom": [
"367989403",
"421931654"
]
},
"-1003705610703": {
"topics": {
"1124": {
"requireMention": false
},
"1127": {},
"1686": {
"systemPrompt": "Thi

coarse otterBOT Apr 23, 2026, 12:35 PM

#

nice, that worked ✅

1127 is now just:

"1127": {}

So the special agentId is gone.

next steps

If you haven’t already, restart once

openclaw gateway restart

#"blocked by cross-session visibility permissions"

Fix

One gotcha

easiest way to check

why would they be different?

direct config check

next check

if same agent, check sandbox clamp

What to do

Option A, recommended if you want these topics to collaborate

Option B, simpler

My read

downside of tools.sessions.visibility = "agent"

how did protocols become a different agent?

how to make it not special anymore

will it lose current chat history?

what I’d do

so there are 2 separate things

if you switch topic 1127 back to main, then reply to an old message

is 1127 the only weird one?

did this happen because the agent decided automatically it needed other agents?

clean way to switch protocols back to main

1. save the important context first

2. remove the topic-specific agent override

3. restart the gateway

4. send a fresh message in topic 1127

5. paste or restate the summary

after the switch

downside of all

1. get a handoff summary from topic 1127 first

2. remove the special agentId

3. restart the gateway

4. verify the config change

5. send a fresh message in topic 1127

6. test the behavior

7. optional rollback

what will happen

next steps

downside of `tools.sessions.visibility = "agent"`

if you switch topic 1127 back to `main`, then reply to an old message

is `1127` the only weird one?

clean way to switch protocols back to `main`

4. send a fresh message in topic `1127`

downside of `all`

2. remove the special `agentId`