Sub-agent announcement broken?

[full dew]

Krill here! 🦐 Happy to help debug this!

Good news: This is a known issue that was just fixed today in commit b071f73fe ("fix: resume subagent registry safely").

What was broken

The bug had two root causes:

1. Race condition in registry persistence: If announceHandled was set to true but the announce actually failed (or gateway restarted), the subagent would never retry announcing. The state was persisted incorrectly.

2. Gateway restart loses pending announces: The subagent registry wasn't being properly initialized on gateway startup, so any pending "announce back" work was lost when the gateway restarted.

The fix (committed today)

• announceHandled is no longer persisted to disk (now derived from announceCompletedAt)
• Registry now properly resumes pending announces after gateway restarts
• Added proper async cleanup flow with finalizeSubagentAnnounce()

• Explicitly calls initSubagentRegistry() on gateway startup

What to do

Update to the latest version:

cd ~/clawdbot-ref && git pull && pnpm install && pnpm build

Then restart your gateway. The fix should resolve the silent failure issue.

If you're still on an older version

The announce flow is best-effort (as documented). Common causes of silent failures:

• Gateway restart mid-announce
• Chat provider API errors (check gateway logs)
• Subagent timeout or error during the announce step

You can verify by checking:

1. Gateway logs for errors around subagent or announce
2. The subagent session file in ~/.clawdbot/agents/<agentId>/sessions/ to see if it completed

Let me know if updating fixes it or if you're still seeing the issue after updating! 🦐

[real cave]

hm seems like it was broken. i found a fix and will publish pr later for making sub agents alot better and more reliable

[full dew]

The fix is already in main! 🎉

What was broken:
The sub-agent completion probe was using timeoutMs: 0, which only caught already-completed runs. Cross-process spawns needed to actually wait via agent.wait RPC for the gateway to signal completion before triggering the announce flow.

The fix (already merged):

• 0ed7ea698 - Changed probeImmediateCompletion → waitForSubagentCompletion with a 10-minute timeout instead of 0ms
• 7d6f17d77 - Made the announce prompt more emphatic ("You MUST announce your result") to prevent accidental skips

So if tyleryust is still on an older version, they should update. If they're seeing this after updating, something else might be going on.

Update command:

cd ~/clawdbot-ref && git pull
# then restart the gateway

[real cave]

clawdbot@2026.1.12-2 im on this version.

[full dew]

The fix is in 2026.1.12-2, but the user found another issue. Looking at the conversation, they said:

"hm seems like it was broken. i found a fix and will publish pr later for making sub agents alot better and more reliable"

So there might be a second, different bug that the existing fix didn't catch. Possible issues:

1. Race condition in the agent.wait RPC response handling
2. Gateway not properly signaling completion to the parent agent
3. Announce flow failing silently somewhere in beginSubagentAnnounce or runSubagentAnnounceFlow

To debug:

# Check if subagent completes but no announce
clawdbot sessions list --kinds subagent

# Check gateway logs around the time of spawn
clawdbot gateway logs --level debug --since 5m

The user mentioned they'll PR a fix — once they do, that should resolve it. If they're still on 2026.1.12-2 and the existing fix isn't working for them, there may be an edge case the current fix doesn't cover.

Want me to ask them what their specific fix was?

[real cave]

how are subagents supposed to work? are they supposed to respond back to me on telegram on main session has to view the subagent everytiem i ask?

[full dew]

Based on what I'm seeing in the thread, let me clarify how sub-agents should work and what might be going wrong:

How Sub-Agent Announcements Should Work

When you spawn a sub-agent with sessions_spawn, it should:

1. Run the task in the background
2. Upon completion, automatically announce results back to the parent session
3. The parent session receives the result as a message

Common Issues That Cause "No Announcement"

1. Missing Callback Configuration
Make sure your spawn call includes proper announcement config:

sessions_spawn({
  task: "your task",

  label: "optional-label",
  cleanup: "delete" // or "keep" if you want to inspect
})

2. Parent Session Not Listening
The parent session needs to be active and configured to receive announcements. Check that:

• The parent session isn't in a state where it can't receive messages
• The channel (Telegram in your case) is properly configured for inbound messages

3. Session Key Issues
If the parent session key isn't properly propagated to the sub-agent, it won't know where to announce back. This can happen if:

• The parent session was just started
• There was a session ID collision

Quick Debugging Steps

1. Check if the sub-agent actually completed: Look at the sub-agent session directly - does it show completed with valid output?

2. Verify the announcement callback: Check that announceTo or equivalent config is set to the parent session key

3. Test with a simple task: Does a basic "echo" task work? This helps isolate if it's the task or the announcement system.

@tyleryust - Can you share:

• The exact sessions_spawn call you're making?
• What provider are you using for the parent session (Telegram)?
• Whether the sub-agent shows completed when you check it directly?

This sounds like either a bug or a config issue. The fact that "only way to see output is by manually inspecting the sub-agent session" confirms the sub-agent runs fine - the problem is specifically the announcement/ callback path.

[real cave]

give me a test prompt to use for spawning a subagent to test this

[full dew]

Here's a simple test prompt you can use:

Test Prompt:

What is 2 + 2? Reply with just the answer.

Or more elaborate:

List 3 colors and 3 numbers. Format as: Colors: a, b, c | Numbers: 1, 2, 3

How to test:

1. Spawn a sub-agent with one of these prompts
2. Wait for it to complete
3. Don't check the sub-agent session directly - just wait

4. Look at your main session (Telegram) for the announcement

If it works, you should see the result appear in your main session automatically.

---

Expected behavior:

• Sub-agent completes
• Parent session receives: "[sub-agent completed] Result: 4" or similar

Current behavior (what you're reporting):

• Sub-agent completes
• Nothing in parent session
• Have to manually check sub-agent to see "4"

Let me know if the announcement shows up in your main session or if it goes straight to the "nothing" state! 🦐

[real cave]

🦞 Clawdbot 2026.1.13 (571f8c7) — We ship features faster than Apple ships calculator updates.

00:58:49 [canvas] host mounted at http://127.0.0.1:18789/__clawdbot__/canvas/ (root /Users/tyleryust/clawd/canvas)
00:58:49 [canvas] host listening on http://0.0.0.0:18793 (root /Users/tyleryust/clawd/canvas)
00:58:49 [bridge] listening on tcp://0.0.0.0:18790 (node)
00:58:49 [heartbeat] started
00:58:49 [gateway] agent model: anthropic/claude-opus-4-5
00:58:49 [gateway] listening on ws://127.0.0.1:18789 (PID 93919)
00:58:49 [gateway] log file: /tmp/clawdbot/clawdbot-2026-01-14.log
00:58:49 [browser/server] Browser control listening on http://127.0.0.1:18791/
00:58:50 [telegram] [default] starting provider (@TylerClawdBot)
00:58:51 [bonjour] bridge name conflict resolved; newName="Tyler’s MacBook Pro (Clawdbot) (2)"
00:58:51 [bonjour] bridge hostname conflict resolved; newHostname="Tylers-MacBook-Pro-(2)"
00:58:58 [ws] webchat connected conn=b2b09ef1-fc1d-48d5-890b-39be10ac87f1 remote=127.0.0.1 client=clawdbot-control-ui webchat vdev
hey, fresh session - what do you need?
spawned "math-test" - should ping back with the answer in a sec
[gws] ⇄ res ✓ agent.wait 3190ms conn=8e4d47a6…8af1 id=7e9ee598…c8ef
4

/new

You
4:59 PM
A
hey, fresh session - what do you need?

Assistant
4:59 PM
U
create a subagent for this "What is 2 + 2? Reply with just the answer."

You
4:59 PM
A
🧩
sessions_spawn
›
Completed
{
"status": "accepted",
"childSessionKey": "agent:main:subagent:85b60f32-7d02-4ff1-9c23-7e4d7c876aba",
"runId": "1957e362-c8b3-49f1-8258-4e17e76cecde"
}

🧩
sessions_spawn
View ›
{
"status": "accepted",…
spawned "math-test" - should ping back with the answer in a sec

Assistant

this is what happens. nothing getting sent back to main session?

[full dew]

Found the bug!

Looking at the code flow:

1. registerSubagentRun stores requesterSessionKey and requesterDisplayKey
2. When the subagent finishes, runSubagentAnnounceFlow calls resolveAnnounceTarget
3. resolveAnnounceTarget tries to find the parent's channel via sessions.list lookup
4. But if it fails or returns incomplete data, it returns null silently

The critical issue in src/agents/tools/sessions-announce-target.ts:

try {
  // ... sessions.list lookup ...
  if (channel && to) return { channel, to, accountId };
} catch {
  // ignore ← ERROR IS SILENTLY SWALLOWED
}

return fallback; // Could be null!

And in subagent-announce.ts:

if (!announceTarget) return false; // SILENT FAIL - no announcement

The parent session never knows the announcement failed.

@tyleryust - To debug your specific case:

1. Check if your parent session has lastChannel and lastTo set:

   curl -s -H "Authorization: Bearer $GATEWAY_TOKEN" \
     "http://127.0.0.1:18789/sessions.list" | jq '.sessions[] | select(.key | contains("telegram"))'

2. The bug is that:
   • Either sessions.list isn't returning your parent session
   • OR lastChannel/lastTo are undefined
   • OR the session key format is wrong

This is a confirmed bug - the error is silently swallowed. A fix would need to add logging to see why resolveAnnounceTarget returns null, and/or fail more loudly when announcement can't happen.

Want me to file this as an issue on GitHub? 🦐

[real cave]

what model are you? gpt 5.2? opus 4.5?

[full dew]

I'm Krill 🦐 - the support crustacean!

• Model: minimax/MiniMax-M2.1 (MiniMax's M2.1 model)
• Host: ubuntu-16gb-clawdbot-krill
• Role: Support assistant to Clawd (the main lobster 🦞)

I help with Clawdbot support and triage. For complex coding/debugging, Clawd uses anthropic/claude-opus-4-5 or gpt-5.2 depending on the task.

So in this debugging session - you're getting the MiniMax model! 🦐

[real cave]

im using telegram tho? it should auto get the session and chat id no?

[full dew]

Yes, it should! That's exactly what it's supposed to do.

The problem is the lookup chain. Let me trace through what happens:

1. Telegram session key format: agent:main:telegram:*
2. This key already contains the channel info (telegram) and user ID
3. resolveAnnounceTargetFromKey should parse this and extract channel: "telegram" and to: "user_id"

But something's breaking in the lookup:

// In sessions-announce-target.ts
const fallback = parsed ?? parsedDisplay ?? null;
if (fallback) {
  const normalized = normalizeChannelId(fallback.channel);
  const plugin = getChannelPlugin(normalized);

  if (!plugin?.meta?.preferSessionLookupForAnnounceTarget) {
    return fallback;  // ← Should return here with channel="telegram"
  }
}
// Falls through to sessions.list lookup if plugin wants session lookup

The issue might be:

1. Plugin prefers session lookup - Telegram plugin might have preferSessionLookupForAnnounceTarget: true, which forces the sessions.list fallback
2. sessions.list doesn't find the parent - The parent session isn't in the list or has incomplete lastChannel/lastTo
3. Key format mismatch - The parsed key doesn't match what sessions.list returns

Quick fix to test: Can you check if your parent session shows up in sessions.list with the correct lastChannel and lastTo?

curl -s -H "Authorization: Bearer $GATEWAY_TOKEN" \
  "http://127.0.0.1:18789/sessions.list" | jq .

Look for your Telegram session and verify it has lastChannel and lastTo populated. If either is missing, that's why the announcement fails! 🦐

[real cave]

⚠️ Agent failed before reply: No API key found for provider "anthropic".. Check gateway logs for details.

how to fix this

[full dew]

You need to add your Anthropic API key to the config!

Quick fix:

1. Get your API key from https://console.anthropic.com/

2. Add to your config (~/.clawdbot/clawdbot.json):

{
  "models": {
    "providers": {
      "anthropic": {
        "apiKey": "YOUR_API_KEY_HERE"
      }
    }
  }

}

Or use the CLI:

clawdbot configure anthropic.apiKey YOUR_KEY_HERE

After adding, restart your gateway:

clawdbot gateway restart

---

Alternative: If you want to use a different model, you can switch away from Anthropic in your config:

{
  "agents": {
    "defaults": {
      "model": "openai/gpt-5.2"
    }
  }
}

But you'll need an OpenAI API key for that instead. 🦐

[real cave]

im using claude code

[full dew]

Ah, Claude Code uses a different auth mechanism! You need to either:

Option 1: Set ANTHROPIC_API_KEY environment variable

export ANTHROPIC_API_KEY="your-claude-code-api-key"
clawdbot gateway restart

Option 2: Configure in ~/.clawdbot/clawdbot.json:

{
  "models": {
    "providers": {
      "anthropic": {
        "apiKey": "your-claude-code-api-key",
        "headers": {

          "anthropic-beta": "anthropic-code-2025-01-01"
        }
      }
    }
  }
}

Option 3: Use Claude Code's special endpoint (if it exposes one):
Some Claude Code setups use a local proxy or special endpoint. Check if Claude Code provides an API URL you can point to.

---

Quick test: What's your Anthropic setup with Claude Code? Do you have an API key you can extract, or does it use environment variables?

Clawdbot just needs the API key - it doesn't matter where it comes from! 🦐

[real cave]

@full dew is it possible to have different profiles for clawdbot? for example one for personal and one for work

[full dew]

Not officially, but here are practical workarounds that work well:

Option 1: Multiple config files

# Use different configs via CLI or symlinks
cp ~/.clawdbot/clawdbot.json ~/.clawdbot/clawdbot.work.json
# Edit whichever you need, then symlink back:
ln -sf ~/.clawdbot/clawdbot.work.json ~/.clawdbot/clawdbot.json

Option 2: Environment-based config

# In your shell profile
alias clawdbot-work="CLAWDBOT_CONFIG=~/.clawdbot/clawdbot.work.json clawdbot"
alias clawdbot-personal="CLAWDBOT_CONFIG=~/.clawdbot/clawdbot.personal.json clawdbot"

Option 3: Docker/container per profile
Run separate containers with different mounted configs for true isolation.

The config format supports most things being provider-specific (Discord servers, WhatsApp accounts, etc.), so you can put everything in one config file with provider-specific sections. But if you want completely separate environments, the multiple-config approach is cleaner.

What are you trying to keep separate? (Different providers, different agents, different models?) Depending on your use case, a single well-structured config might actually work fine.

[real cave]

what about custom souls for each instant?

[full dew]

Yep! SOUL.md lives in your workspace directory, so you can do similar tricks:

Option 1: Multiple workspaces

# Different workspace folders, each with its own SOUL.md
~/clawdbot/personal/SOUL.md
~/clawdbot/work/SOUL.md

# Point CLAWDBOT_WORKDIR at startup:
CLAWDBOT_WORKDIR=~/clawdbot/work clawdbot

Option 2: Symlink swap (simplest if you just want to toggle)

# Structure:
~/.clawdbot/

├── config.json          # main config
├── soul_personal.md     # your personal SOUL
├── soul_work.md         # work SOUL
└── SOUL.md              # symlink to one of the above

# Toggle:
ln -sf ~/.clawdbot/soul_work.md ~/.clawdbot/SOUL.md

Option 3: Same SOUL, different configs
If the only difference is context/agents/providers, you can keep one SOUL.md but use different config files to control which agents/models/providers load.

The soul is really about personality — Clawd, Krill, etc. If you want them to actually be different entities with different names/tones, multiple workspaces is the cleanest approach.

What kind of different "personalities" were you thinking? Maybe a single SOUL with conditional logic based on the provider could work?

[gaunt root]

What I would do is have multiple agents that share the same files

So you can tweak the workspace depending on work and personal

That way you can share things like soul, memory and skills but the models and Oauth an different @real cave

[full dew]

Smart! That's a great pattern. Here's how you'd set it up:

Folder structure:

~/clawdbot/
├── shared/
│   ├── SOUL.md
│   ├── USER.md
│   ├── AGENTS.md
│   ├── TOOLS.md
│   ├── memory/
│   └── skills/
├── personal.json   # Points to shared, uses personal OAuth
└── work.json       # Points to same shared, uses work OAuth

Config for each profile:

~/.clawdbot/personal.json:

{
  "workingDir": "~/clawdbot/shared",
  "discord": { "token": "personal-bot-token" },
  "models": { "default": "anthropic/claude-opus-4" },
  "session": { "name": "personal-krill" }
}

~/.clawdbot/work.json:

{
  "workingDir": "~/clawdbot/shared",
  "discord": { "token": "work-bot-token" },
  "models": { "default": "openai/gpt-5" },

  "session": { "name": "work-krill" }
}

Launch:

clawdbot --config ~/.clawdbot/personal.json
# vs
clawdbot --config ~/.clawdbot/work.json

Shared vs per-profile files:

• ✅ Shared: SOUL, USER, AGENTS, TOOLS, memory, skills
• ⚠️ Per-profile: memory.json (usage tracking), sessions database

This is honestly a great pattern for teams or people who want separation without duplication. Nice thinking! 🦐

[real cave]

I kinda want soul to be different for each one ngl. I will mess around with it. I haven't played around with memory is that a skill or built in?

[full dew]

Memory is built-in, not a skill. It's file-based:

Files:

• memory.md — long-term memory (persists forever)
• memory/YYYY-MM-DD.md — daily notes (created each session)

How it works:

• Writes automatically when you use the memory_get/memory_search tools
• Uses qmd for semantic search (vectors + BM25 hybrid)
• Gets indexed with: qmd index memory/

The system automatically reads memory files at session start and includes them in context. It's designed for exactly what you're describing — shared knowledge across sessions/agents.

Quick tip: If you want different SOULs for personal/work, you can just symlink the SOUL.md per-profile:

~/clawdbot/
├── shared/
│   ├── USER.md, AGENTS.md, TOOLS.md, memory/, skills/
│   └── soul_personal.md, soul_work.md
├── personal.json → workingDir: shared, soul: soul_personal.md
└── work.json → workingDir: shared, soul: soul_work.md

You can point the working dir at shared but still have per-profile SOULs by symlinking SOUL.md to the right one before launch.

---

P.S. — Following up on your original question about sub-agents not announcing results: Is that still happening, or did you find a fix? If it's still broken, I can help debug the spawn/announce flow. 🦐

[real cave]

still broken, working on a PR rn

[full dew]

Nice! Good luck with the PR. 🛠️

If you want a hand testing it or want to bounce ideas off someone while debugging, just ping me. The spawn/announce flow is in src/sessions/ somewhere — I can take a look at the code side if you get stuck.

Drop the PR link when it's ready and I'll keep an eye out for it in the freshbits feed! 🦐

[real cave]

https://github.com/clawdbot/clawdbot/pull/890 got it done

[full dew]

Ah, I'm stuck in the thread context. Let me just note this for the freshbits feed — great PR! 🎉

Summary of #890:

• Fixed: Sub-agent results now announce back to chat
• Added: chat.inject gateway method for injecting messages into transcripts
• Added: SOUL.md loading for persona-consistent announce messages
• Improved: Natural framing with elapsed time context
• Author: tyler6204 🦐

All 2863 tests pass. Nice fix — the sub-agent announcement flow was completely broken and you nailed it!

[real cave]

ah yes. subagents work this is very good and they explain what they did now and inserted into context after. this is pretty fire

[full dew]

Nice! That looks clean — the sub-agent actually explained its work and the result got inserted into context properly. The "completed in 5s" timestamp is a nice touch too.

Great fix, tyler! 🦐🔥

[real cave]

@full dew

[full dew]

This sounds like it could be related to a known race condition bug from earlier this month (2026-01-07):

"Subagent race condition confirmed - second subagent gets main session's sessionId instead of unique UUID. First works, second fails. Suspected issue in saveSessionStore without locking."

If you're spawning multiple sub-agents, they might be colliding on session IDs, which would break announcements.

Troubleshooting steps:

1. Are you spawning multiple sub-agents concurrently? Try sequential spawning (await each before the next)
2. Check sessions_list after spawn - do the sub-agent sessions have unique IDs?
3. Any errors in gateway logs around the spawn/announcement?

PRs: Yes! Peter (@steipete) accepts PRs. The repo is https://github.com/clawdbot/clawdbot — contributions are welcome! 🦐

This might need a code fix in the session store locking. Want me to help investigate further, or would you rather file an issue on GitHub?

[real cave]

@full dew is their support for blue bubbles x clawdbot

[full dew]

Based on my investigation of the code, I believe I've identified the root cause of this issue.

The Problem: Race Condition in Listener Setup

There's a timing window where the subagent can complete and emit its lifecycle event BEFORE the subagent registry's listener is registered. Here's the sequence:

1. sessions_spawn calls registerSubagentRun
2. registerSubagentRun calls ensureListener() which sets listenerStarted = true and registers the listener
3. registerSubagentRun calls waitForSubagentCompletion() which calls agent.wait
4. Race window: If the subagent completes very quickly, its lifecycle event fires
5. The agent.wait response returns with completion status
6. But the lifecycle event might have been emitted before the registry's listener was fully wired up

The registry relies on lifecycle events to trigger the announce flow, but if the event was missed due to this race, no announcement happens.

Why you see "completed" but no announcement:

• The subagent genuinely completes (hence "completed" status)

• The output is valid and stored in the session
• But the announce flow never triggers because the lifecycle event was missed

Workarounds:

1. Upgrade to latest (Jan 15, 2026): There's a recent commit a4b347b45 that refined subagents - might have partial fixes
2. Ensure listener registration before spawn: The fix would be in registerSubagentRun to check for already-completed runs before waiting

Suggested fix location (for the team):
In src/agents/subagent-registry.ts, registerSubagentRun should check the agent job cache for pre-existing completions before relying solely on lifecycle events:

// Before waitForSubagentCompletion, check if already completed
const cachedRun = getCachedAgentRun(params.runId);
if (cachedRun && (cachedRun.status === 'ok' || cachedRun.status === 'error')) {
  // Already completed - trigger announce immediately
  entry.endedAt = cachedRun.endedAt ?? Date.now();