Discrepancies and security issues

[dwbutler]

Hi, thanks for creating this project. I'm interested in trying it, so I cloned the source code, threw it into Codex, and asked:

Examine this project and tell me whether it does what it says (in the README) and whether you find anything insecure that should concern me about running this in a separate user account and sandboxed (so dockerized)

I think this answer potentially indicates real issues:

Short answer: partially. The core architecture is real, but there are important README mismatches and at least one critical security issue.

Security Findings (highest risk first)

1. Critical: remote command injection via message text
   Untrusted message content is interpolated into a shell command in execSync(...) and only " is escaped, so shell expansions like $(...) can execute.
   Reference: /Users/Shared/tinyclaw/src/queue-processor.ts:97

2. High: untrusted users can drive Claude with full local permissions
   Incoming Discord/WhatsApp messages are forwarded to Claude with --dangerously-skip-permissions, and there is no sender allowlist. Any DM (Discord) or direct chat (WhatsApp) can trigger privileged actions inside the runtime account/container.
   References: /Users/Shared/tinyclaw/src/queue-processor.ts:97, /Users/Shared/tinyclaw/src/discord-client.ts:129, /Users/Shared/tinyclaw/src/whatsapp-client.ts:140

3. Medium: Chromium sandbox explicitly disabled
   WhatsApp Puppeteer runs with --no-sandbox and --disable-setuid-sandbox. In Docker this is common, but it increases impact if browser content is exploited.
   Reference: /Users/Shared/tinyclaw/src/whatsapp-client.ts:69

4. Medium: plaintext secrets and chat snippets at rest
   Discord token is stored in .tinyclaw/settings.json and copied to .env; logs include sender/message snippets.
   References: /Users/Shared/tinyclaw/setup-wizard.sh:97, /Users/Shared/tinyclaw/tinyclaw.sh:108, /Users/Shared/tinyclaw/src/discord-client.ts:141, /Users/Shared/tinyclaw/src/whatsapp-client.ts:145

Does it match README?

• Mostly yes: Discord/WhatsApp clients, queue-based processing, tmux orchestration, and conversation continuity are implemented.
• Not accurate in key places:

1. README says Discord supports “DMs and mentions”, but code ignores guild messages (mentions in servers).
   References: /Users/Shared/tinyclaw/README.md:199, /Users/Shared/tinyclaw/src/discord-client.ts:130
2. README says model switching works via settings, but queue processor reads .tinyclaw/model (never written), not .tinyclaw/settings.json.
   References: /Users/Shared/tinyclaw/README.md:166, /Users/Shared/tinyclaw/src/queue-processor.ts:17, /Users/Shared/tinyclaw/setup-wizard.sh:96, /Users/Shared/tinyclaw/tinyclaw.sh:501
3. README documents ./tinyclaw.sh logs queue, but tinyclaw.sh has no queue log case.
   References: /Users/Shared/tinyclaw/README.md:173, /Users/Shared/tinyclaw/tinyclaw.sh:397
4. README says Node v14+, but locked deps require Node >=18.
   References: /Users/Shared/tinyclaw/README.md:49, /Users/Shared/tinyclaw/package-lock.json:893, /Users/Shared/tinyclaw/package-lock.json:2227

For your separate account + Docker plan
Running in a separate user and container helps, but as-is I would still treat this as unsafe against untrusted message senders until the critical injection and permission model are fixed.
If you must run now, isolate hard: non-root container, no privileged mode, no Docker socket, minimal/no host mounts, and strict outbound network limits.

I did a static audit (no live Discord/WhatsApp/Claude execution).

[jlia0]

Thank you for pointing out the discrepancies, will address those with sub issues. Thanks!

[0x177630b6]

Hi,

Great analysis @dwbutler -- I've been looking at this on my end too.

@jlia0 Nice work keeping this minimalist — it really improves trust and readability.

Wanted to flag that #2 (no sender allowlist) is probably the most urgent blocker for anyone wanting to actually use this in production. The other issues have workarounds (Docker isolation, sandboxing), but without a way to restrict who can talk to the bot, you're essentially exposing --dangerously-skip-permissions to the entire internet.

Right now the only filtering is "is this a DM?" (Discord/Telegram) or "is this not a group?" (WhatsApp) -- but within those, every user is accepted.

A minimal first step would be allowed_users and allowed_groups per channel in settings.json:

"telegram": { "allowed_users": ["123456789"] },
"whatsapp": { "allowed_users": ["6591234567@c.us"] },
"discord": { "allowed_users": ["108234567890123456"] }

Empty or missing = allow all (backwards compatible). Each channel client checks before writing to the queue. No restart needed since settings are read per-message.

The tricky part is discoverability -- you need to know your Telegram ID, WhatsApp JID, or Discord user ID to add yourself. A /whoami command in each channel client that replies with the sender's ID would make onboarding much easier (send /whoami, copy the ID, paste into settings, done).

Would it make sense to prioritize this as a sub-issue? Happy to contribute.

[jlia0]

Hi,

Great analysis @dwbutler -- I've been looking at this on my end too.

@jlia0 Nice work keeping this minimalist — it really improves trust and readability.

Wanted to flag that #2 (no sender allowlist) is probably the most urgent blocker for anyone wanting to actually use this in production. The other issues have workarounds (Docker isolation, sandboxing), but without a way to restrict who can talk to the bot, you're essentially exposing --dangerously-skip-permissions to the entire internet.

Right now the only filtering is "is this a DM?" (Discord/Telegram) or "is this not a group?" (WhatsApp) -- but within those, every user is accepted.

A minimal first step would be allowed_users and allowed_groups per channel in settings.json:

"telegram": { "allowed_users": ["123456789"] }, "whatsapp": { "allowed_users": ["6591234567@c.us"] }, "discord": { "allowed_users": ["108234567890123456"] }

Empty or missing = allow all (backwards compatible). Each channel client checks before writing to the queue. No restart needed since settings are read per-message.

The tricky part is discoverability -- you need to know your Telegram ID, WhatsApp JID, or Discord user ID to add yourself. A /whoami command in each channel client that replies with the sender's ID would make onboarding much easier (send /whoami, copy the ID, paste into settings, done).

Would it make sense to prioritize this as a sub-issue? Happy to contribute.

I have created issue #29, I would really appreciate if you could contribute to this as well.

I agree, there isn't a way to gather the sender ID until the channel receives a message, maybe we can save those messages as a collection of sender IDs?