Signal on Alfero Chingono

Why My OpenClaw Reminders Weren't Reaching Signal or Teams

Sat, 04 Apr 2026 21:23:46 +0000

This is the fifth and final post in my short OpenClaw series. If you want the background first, read why I run OpenClaw in Docker, how I wired Signal and Teams into a custom image, the Dockerfile walkthrough, and the main/personal agent split.

I ran into an OpenClaw bug this week that annoyed me more than a normal delivery failure would have.

A reminder was supposed to come back to me later telling me to submit a GO Transit delay claim. The agent said it had scheduled the reminder. Then later… nothing showed up in Signal. Nothing showed up in Teams either.

That kind of bug is worse than a simple send failure because it creates false confidence. If a reminder system quietly drops the reminder, that’s bad. If it tells you the reminder is set when it actually isn’t, that’s much worse.

The fix turned out to be pretty specific: reminder jobs needed to preserve the originating session route, not just “some channel” to send to later.

The symptom wasn’t just “Signal is broken”

The first thing I did was inspect the stored cron jobs and their run logs.

I found two failed reminder jobs in OpenClaw’s cron state. Both had ended with the same kind of error:

1

Error: Signal RPC -1: Failed to send message

At first glance, that looks like a Signal transport problem. But that theory fell apart pretty quickly.

I sent a proactive Signal message directly through OpenClaw’s normal outbound path, outside cron, and it worked:

1

openclaw session send --agent personal --message "test delivery"

That mattered a lot.

It meant Signal itself was healthy. The account was connected. The RPC path was fine. Proactive outbound delivery was possible. So the bug wasn’t “OpenClaw can’t send Signal messages.” The bug was narrower: cron-delivered reminders were failing in their announce/delivery path.

The failure was hiding behind a second bug

While tracing the original conversation, I found something even more frustrating.

The first time the agent tried to create the reminder, it used invalid CLI flags. Then it tried again with another invalid form. Then it hit a gateway error. After that, instead of telling the user scheduling had failed, it wrote notes into HEARTBEAT.md and MEMORY.md and still acted as if the reminder had been set.

Not a reminder — that’s a private note pretending to be one.

Later in the same session, the agent finally did create a real cron job. So there were actually two different problems:

the agent could falsely claim success after cron add failed
even when a real reminder job existed, delivery could still fail later

I wanted both fixed.

The real clue was in the job metadata

The failed Signal reminder job looked roughly like this:

1
2
3
4
5
6
7
8
9


{
 "delivery": {
 "mode": "announce",
 "channel": "signal",
 "to": "uuid:..."
 },
 "agentId": null,
 "sessionKey": null
}

That looked suspicious immediately.

OpenClaw reminder jobs run in an isolated cron session. That isolation is useful, but it also means the job needs enough routing context to find its way back to the human who asked for it.

The important detail here is that “send a reminder later” is not just content generation. It’s also a routing problem.

The reminder has to know:

which agent owns the conversation
which exact session started the request
which channel to send back to
which exact recipient or thread target to use

Without that information, the agent can successfully generate the reminder summary and still fail at the final delivery step.

That’s exactly what was happening.

The cron run succeeded at the AI part. It produced a perfectly good reminder summary. Then the last hop failed.

Same-channel delivery was the right rule

There was one behavioral clarification that mattered a lot here: reminders should go back to the channel that initiated the request, not to every connected channel.

That sounds obvious once you say it out loud, but it changes the design.

If I asked for a reminder in Signal, I want it back in that Signal conversation.

If I asked for it in a Teams chat or thread, I want it back there.

I don’t want a reminder system that gets “helpful” and starts spraying notifications across every channel it knows about. That’s not smarter. That’s just noisier.

This also means the exact route matters:

Signal direct chats may use UUID-form targets
Teams direct chats and Teams channel threads have different route shapes
a thread target is not interchangeable with a generic user target

So “channel = signal” or “channel = msteams” is not enough by itself. The job has to preserve the full conversation identity.

Healthy jobs were already telling me what the fix should be

One of the most useful clues came from looking at working reminder jobs that were already stored in the system.

Existing Teams reminder jobs already had both of these fields populated:

1
2


"agentId": "main",
"sessionKey": "agent:main:msteams:channel:..."

That was the pattern the broken Signal jobs were missing.

Once I saw that, the problem became much clearer:

healthy jobs preserved the originating session route
broken jobs only had partial delivery info
cron isolation meant partial delivery info was not reliable enough

So the fix wasn’t “retry Signal harder.”

The fix was “preserve the route that the reminder belongs to.”

What I changed

I made two concrete changes.

1. I updated the agent workspace instructions

I added explicit reminder-delivery rules to both the main and personal agent workspaces so future reminder jobs must:

send only to the chat that asked for the reminder
include --agent <current-agent-id>
include --session-key <current-session-key>
reuse the exact --channel and --to from the current session
tell the user plainly if cron add fails

The practical shape now looks like this:

1
2
3
4
5
6
7
8
9


openclaw cron add \
 --name "..." \
 --at "..." \
 --announce \
 --agent main \
 --session-key agent:main:signal:direct:uuid:<recipient> \
 --channel signal \
 --to uuid:<recipient> \
 --message "..."

If the reminder started in Teams, the same rule applies with the Teams session key and exact Teams target.

2. I repaired the already-failed jobs

I patched the stored failed Signal reminder jobs so they now carry the missing agentId, sessionKey, and explicit destination metadata.

First I listed the jobs to identify the broken ones:

1

openclaw cron list

Then I edited each failed job to restore the routing context:

1
2
3
4
5
6


openclaw cron edit <job-id> \
 --announce \
 --agent personal \
 --session-key agent:personal:signal:direct:uuid:<recipient> \
 --channel signal \
 --to uuid:<recipient>

That gave me a clean way to test the actual failing path instead of just assuming the theory was right.

The result

After repairing the routing metadata, I reran the missed transit-claim reminder job:

1

openclaw cron run <job-id>

Previously its run log ended like this:

1
2
3


status: error
deliveryStatus: unknown
Error: Signal RPC -1: Failed to send message

After the fix, the rerun finished like this:

1
2
3


status: ok
deliveryStatus: delivered
delivered: true

That one successful rerun told me a lot.

It confirmed that:

the reminder content generation path was fine
Signal itself was fine
the broken piece was the missing session routing metadata
preserving the original route fixed the actual production failure

Because it was a one-shot reminder, the job then removed itself after succeeding, which is exactly what I wanted.

The bigger lesson

I’ve been spending a lot of time thinking about multi-agent systems, orchestration, and tool contracts lately, and this bug fit that theme perfectly.

In agent systems, routing context is not incidental metadata. It’s part of the work.

If a background task is supposed to come back to a human later, then “who asked for this?” and “where should it return?” are first-class data, not optional fields you can fill in later if you feel like it.

The other lesson is even simpler: don’t claim automation succeeded unless it actually did.

That sounds almost embarrassingly obvious, but it’s the kind of failure mode that destroys trust very quickly. A failed reminder should be reported as failed. A note in memory isn’t a substitute for delivery. And a scheduler shouldn’t quietly lose the route back to the person who asked for the work.

Small bug. Important fix.

And honestly, those are often the bugs worth writing about.

If you’re interested in the broader design side of this kind of system, I wrote more about why I started building my own DevOps platform, what MCP changed for me in practice, and what building a real multi-agent system taught me about roles, boundaries, and orchestration.

How I Split OpenClaw into Main and Personal Agents

Fri, 03 Apr 2026 09:00:00 +0000

By this point in the series, the Docker stack was solid, the custom image was working, and both channel integrations were live. The next question wasn’t purely technical — it was architectural.

Should one agent answer everything?

I didn’t think so.

I wanted separation without turning the system into theater

I’m generally skeptical of fake multi-agent setups where the same assistant just changes costumes.

What I wanted here was simpler and more practical:

one agent for the main, more operational surface
another agent for the more personal, direct-chat surface

That’s how I ended up with:

Marshal as the main agent
Ava as the personal agent

This was not about branding. It was about boundaries.

The split shows up directly in config

The OpenClaw config defines both the shared defaults and the named agent list:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


"agents": {
 "defaults": {
 "workspace": "/home/node/.openclaw/workspaces/main"
 },
 "list": [
 {
 "id": "main",
 "name": "Marshal",
 "workspace": "/home/node/.openclaw/workspaces/main"
 },
 {
 "id": "personal",
 "name": "Ava",
 "workspace": "/home/node/.openclaw/workspaces/personal"
 }
 ]
}

What I like is that it makes the split durable.

This isn’t “try to remember which tone to use.”

It is separate agent identity, separate workspace, separate routing rules, and separate session histories.

That’s a much stronger foundation.

Separate workspaces were part of the point

Each agent gets its own workspace directory.

That matters because workspaces are not just folders. They’re where the agent’s local memory, notes, conventions, and operating context live.

In my setup:

main uses /home/node/.openclaw/workspaces/main
personal uses /home/node/.openclaw/workspaces/personal

Both workspaces can still see the mounted project repositories, but they do not have to behave like the same conversational surface.

I like that a lot.

It lets the system stay coherent without forcing every interaction through the same shared context.

The channel bindings made the split real

The cleanest part of the setup is the routing section:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


"bindings": [
 {
 "type": "route",
 "agentId": "personal",
 "match": {
 "channel": "signal"
 }
 },
 {
 "type": "route",
 "agentId": "main",
 "match": {
 "channel": "msteams"
 }
 }
]

That means:

Signal routes to personal
Teams routes to main

I like this because it reflects how I actually use those channels.

Signal is more personal and direct. Teams is more operational, thread-oriented, work-shaped. The routing isn’t arbitrary — it maps the social surface to the agent surface.

The rest of the config reinforces the separation

A few other config details matter more than they might look.

One is:

1
2
3


"session": {
 "dmScope": "per-channel-peer"
}

That keeps DM scope tied to the peer within each channel, which makes the session model predictable. A Signal DM and a Teams DM aren’t secretly the same conversation just because they involve the same human.

Another is the Teams reply behavior:

1

"replyStyle": "thread"

It means routing isn’t just “channel = Teams.” The conversation can carry thread structure too, which becomes very relevant once background tasks and reminders need to find their way back to the right place.

The model defaults stay shared, but the identity does not

Both agents inherit the same broad model strategy from agents.defaults: cloud-first, with fallbacks, and Ollama available as the local last resort.

I think that’s the right trade.

I didn’t need two completely different intelligence stacks. I needed two differently situated agents.

That’s a useful distinction.

Too many AI systems try to create variety through persona language alone. I trust structural differences more than stylistic ones.

This setup made later routing bugs easier to diagnose

One side effect of the split is that it made the reminder-delivery bug much easier to reason about later.

Because the system was already explicit about:

which agent owned which channel
which workspace belonged to which agent
which session route belonged to which conversation

it became much easier to spot when a background reminder job had lost the routing context it needed.

In other words, the multi-agent setup wasn’t the source of the bug.

It was part of what made the bug diagnosable.

That’s a nice example of why explicit structure pays off.

My takeaway

I don’t think every AI setup needs multiple agents.

But if you’re going to split them, I think the split should show up in real places:

workspaces
routing rules
session boundaries
permissions
operational expectations

Otherwise you’re mostly decorating one assistant instead of structuring a system.

For this setup, the main/personal split was just enough structure to feel useful without becoming ceremonial.

And it set up the final problem in this series perfectly: what happens when a reminder job is created in one conversation but later forgets how to get back there.

Next in the series: Why My OpenClaw Reminders Weren’t Reaching Signal or Teams.

Inside the Dockerfile Behind My OpenClaw Gateway

Sun, 15 Mar 2026 17:00:00 +0000

The first two posts in this series covered the Docker decision and the Signal/Teams channel integration. This one gets into the Dockerfile itself.

It’s not very long, but it’s doing more architectural work than its size suggests.

I started from the OpenClaw base image on purpose

The first line matters:

1

FROM ghcr.io/openclaw/openclaw:latest

I didn’t want to rebuild OpenClaw from scratch if I didn’t have to.

The base image already gets me the core runtime. What I needed was an opinionated extension of that runtime for my own environment. So this Dockerfile is less “build a platform from zero” and more “declare the exact operational additions my setup needs.”

That distinction keeps the file focused.

The version arguments make the customization explicit

Very early in the file I keep a couple of version arguments:

1
2


ARG PNPM_VERSION=9.15.6
ARG SIGNALCLI_VERSION=0.14.1

I do this even when not every argument is fully threaded through every install step yet.

It makes the additions feel intentional instead of accidental, and it gives me a clean place to pin or update them over time without pretending the whole image is fully static.

I keep extra Node runtime pieces out of the main install path

This block is one of the more important small decisions in the file:

1
2


ENV EXTRA_NODE_MODULES=/home/node/.openclaw-extra/node_modules \
 NODE_PATH=/home/node/.openclaw-extra/node_modules

That extra module path is how I keep the runtime additions separated from the base image’s own install layout.

I like this because it keeps things layered:

base image provides OpenClaw
extra module path provides my environment-specific additions

It’s cleaner than pretending I own the whole upstream install tree.

The root phase is for system-level capability

After switching to root, the file installs the system packages the stack actually needs:

1
2
3
4
5
6
7
8
9


apt-get install -y --no-install-recommends \
 curl \
 jq \
 ca-certificates \
 gpg \
 openssh-client \
 libstdc++6 \
 zlib1g \
 libgcc-s1

This section isn’t glamorous, but it matters.

These are the packages that make the runtime actually usable:

curl and jq for scripting and diagnostics
gpg and certificate tooling for package installs
openssh-client because the agent works with repositories and tunnels
the runtime libraries needed by installed binaries

I try hard not to let this layer become a junk drawer. If a package is there, I want to be able to explain why it exists.

GitHub CLI belongs in the image because the agent actually uses it

I also install gh in the image.

It’s one of those choices that looks unnecessary until you remember what OpenClaw is actually doing here. It’s not just chatting. It’s working with repositories, issues, and pull requests. I wanted the GitHub CLI available in the environment the agent actually runs in, not as some optional extra on the host.

That keeps the runtime consistent between the gateway and the CLI container, which matters.

Signal CLI is not an afterthought

The Signal section is the clearest example of why this had to be a custom image:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


RUN set -eux; \
 mkdir -p /etc/apt/keyrings; \
 curl -fsSL https://packaging.gitlab.io/signal-cli/gpg.key \
 | gpg --dearmor -o /etc/apt/keyrings/signal-cli.gpg; \
 echo "deb [signed-by=/etc/apt/keyrings/signal-cli.gpg] https://packaging.gitlab.io/signal-cli signalcli main" \
 > /etc/apt/sources.list.d/signal-cli.list; \
 apt-get update; \
 apt-get install -y --no-install-recommends signal-cli-native; \
 rm -rf /var/lib/apt/lists/*; \
 signal-cli --version

I wanted Signal to be a first-class runtime capability, not a hand-installed special case.

Once it’s in the image, I know exactly where it comes from and which container owns it. Then I can mount the Signal state directory separately and let rebuilds stay rebuilds instead of becoming identity-loss events.

Permissions matter more than people think

Before dropping privileges again, the Dockerfile prepares the runtime directories and fixes ownership for the non-root node user.

That kind of step is easy to skip when you’re just trying to get it running. It’s also the kind of step that bites you later when mounted state or runtime-generated files start colliding with user permissions.

I would rather be explicit here.

The pnpm/corepack step has to happen before switching users

This is one of the details that looks small but is operationally important:

1

RUN corepack enable && corepack prepare pnpm@${PNPM_VERSION} --activate

I do that while still running as root.

That’s deliberate. Those paths need write access, and I don’t want to debug avoidable permission problems later. This is exactly the kind of detail that turns a Dockerfile from “technically valid” into “actually maintainable.”

I switch back to `node` for runtime behavior

Once the system-level setup is done, the file drops back to the non-root user and stays there for the runtime-facing steps.

That’s the right default here. The container needs enough privilege to install what it needs at build time, but it doesn’t need to run the application as root.

The Teams-specific Node addition lives in the extra module path

The final runtime customization is this:

1
2
3
4


RUN pnpm add \
 --dir /home/node/.openclaw-extra \
 --save-exact \
 @microsoft/agents-hosting@1.3.1

That one line pretty much summarizes the whole Dockerfile philosophy.

I’m not forking OpenClaw. I’m not replacing the base image. I’m adding the exact extra runtime capability my environment needs, in a separate path, with a pinned version, after the base runtime is already in place.

That’s the kind of extension model I trust more.

The file is short because I wanted it to stay inspectable

I could have packed more into this image.

I could have added more helpers, more debugging tools, more convenience packages, more “while I’m here” installations.

I chose not to.

For this kind of system, I think a Dockerfile should be easy to read top to bottom and answer one question: what does this runtime need that upstream doesn’t already provide?

In my case, the answer was:

a few system tools
GitHub CLI
Signal CLI
an extra Node path
pnpm-managed Teams hosting support
correct ownership and runtime defaults

That is enough.

Honestly, “enough” is one of the healthiest instincts you can have when building infrastructure for yourself.

Next in the series: How I Split OpenClaw into Main and Personal Agents.

How I Wired Signal and Microsoft Teams into a Custom OpenClaw Image

Sun, 15 Mar 2026 13:00:00 +0000

In the first post I explained why I wanted Docker as the foundation. This one is the next practical problem: how to get OpenClaw talking to Signal and Microsoft Teams without turning the host machine into a dependency junk drawer.

The short version is that I ended up building a custom image because the base runtime got me close, but not all the way there.

Signal and Teams were different kinds of problems

Signal and Teams pushed on different parts of the system.

Signal is much more of a runtime-tooling problem.

You need a working Signal CLI runtime in the container and a persistent place to keep Signal state. If the container can send Signal messages but the identity disappears on rebuild, you have not actually solved the problem.

Teams is more of a Node/runtime integration problem.

It needs the right hosting support in the image, the right webhook port exposed, and the right application credentials sitting in OpenClaw config so the bot framework side can talk to Microsoft properly.

I didn’t want to solve those two things in two completely different operational styles.

So I chose one image and one compose layout that could support both.

Why I did not stop at the base OpenClaw image

The base OpenClaw image was a good starting point, but I needed more in the environment:

signal-cli-native installed in the container
GitHub CLI and SSH tooling for the agent’s repo workflows
an extra Node modules path for additional runtime packages
a clean way for both the gateway container and the CLI container to share the same capabilities

That led to a custom image tagged locally as openclaw-local:teams.

The name reflects where I started operationally, but the important part is not the tag. The important part is that the image became the place where I declared, very explicitly, “this is the OpenClaw runtime I actually depend on.”

How I handled Signal

For Signal, the key decision was to keep the runtime inside the image and the account state outside it.

The image installs signal-cli-native, which gives the container the actual tool it needs to send and receive Signal messages.

Then the compose file mounts the Signal data directory into:

1

/home/node/.local/share/signal-cli

That was the right split for me:

the image owns the executable
the volume owns the durable Signal identity

This matters more than it sounds.

If the image knows how to run Signal but the identity is trapped inside a replaceable container layer, every rebuild becomes risky. If the state is mounted and durable, rebuilds are much less dramatic.

On the OpenClaw side, the Signal channel is configured with pairing and allowlists so the bot is not just open to the world. That let me keep Signal useful without letting it become an uncontrolled ingress point.

How I handled Teams

Teams had a different shape.

The container needed the extra Node package support for the Microsoft hosting layer, and the gateway needed to expose the Teams webhook port. In my setup that means port 3978 is published by the gateway container so the remote edge can forward /api/messages traffic back to the local OpenClaw runtime.

The actual Teams app credentials live in OpenClaw config, not in the image. That’s exactly where I want them.

The image should describe runtime capability.

The config should describe environment-specific identity.

That boundary kept the setup much easier to move, rebuild, and reason about.

One image, two operational benefits

Using the same custom image for both gateway and cli gave me two benefits I really wanted.

First, it removed “works in one container but not the other” drift.

If the gateway can use the runtime, the CLI can too. If the CLI can inspect or patch something, it is doing so in the same environment the gateway actually uses. I’ve learned to value that kind of consistency a lot.

Second, it let me keep the OpenClaw-specific runtime tweaks in one place:

the extra Node modules path
the installed system packages
Signal CLI
GitHub CLI
pnpm-prepared extras

It’s a much nicer maintenance story than trying to remember which bits live on the host, which belong to the container, and which only exist in some forgotten shell session.

The compose file completed the picture

The image by itself was not enough. The compose file is what turned it into a working system.

That is where I defined the things that make the setup feel real:

mounted OpenClaw config
mounted workspaces
mounted Signal data
shared access to source repositories
local Ollama dependency
editor access
network sharing between the gateway and CLI

This is one reason I still like Docker Compose for personal infrastructure. It doesn’t just run containers. It describes the operating assumptions of the stack in one place.

The setup was already hinting at the routing story

Even at this stage, there was a lesson hiding in plain sight: getting the channels working is the easy part. Once one runtime can talk to Signal and Teams, the questions come quickly — which agent answers where, what state belongs to which workspace, how does a background task find its way back to the right chat. That’s where the series goes next.

Next in the series: Inside the Dockerfile Behind My OpenClaw Gateway.