Feature/workspace multi user identity

[QuanCheng-QC]

Summary

• Added multi-user identity support for Workspace conversations.
• Human messages now carry sender metadata so different users can be shown by name instead of all appearing as “you”.
• Added an online users section in the Workspace sidebar.
• Fixed a Launcher/Kimi startup issue where a stale daemon PID could make Start appear to do nothing with no fresh logs.
• Improved Start feedback when the daemon cannot start or an agent does not report as running.

Testing

• npx tsc --noEmit
• node --check for changed launcher/agent-connector files
• node --test test/daemon.test.js

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
openagents-workspace	Ready	Preview, Comment	May 13, 2026 0:22am

[zomux]

Security Review — Changes Requested

The core security model needs rework before this can merge. Sender identity is entirely client-asserted with zero server-side validation, enabling trivial impersonation.

Blocking Issues

1. No server-side identity validation
The backend blindly trusts client-supplied sender_id, sender_name, and sender_type. Any user can impersonate any other user by sending arbitrary metadata in the POST body. The backend must validate sender identity against the auth token/session and strip or ignore client-supplied sender fields that conflict.

2. Client-generated user ID stored in localStorage
For unauthenticated users, crypto.randomUUID() creates the identity. An attacker can trivially change this to another user's ID. Server-side enforcement is needed.

3. Unauthenticated presence events
Anyone can emit workspace.user.joined or workspace.user.left with arbitrary user IDs, enabling ghost-user injection or forcibly removing others from the online list.

4. Email used as user ID
Using user.email as sender_id leaks PII in event payloads stored in the database and makes IDs predictable for targeted impersonation.

5. No input validation on sender_name
No length limit, no character validation on the backend side. Should be validated/sanitized before storage.

Other Issues (non-blocking but should be addressed)

• sendMessage source field changes from human:user to human:<actual-name> — may break downstream consumers parsing source
• Hardcoded Chinese prompt string ('请输入你的名称') — should use i18n or English
• window.prompt() loop with no recovery path if user cancels — chat input permanently disabled

Recommendation

Before merging:

1. Backend must validate sender identity against the auth token or session
2. Strip/ignore client-supplied sender fields when they conflict with authenticated identity
3. Add input validation (length, characters) for sender_name on the backend
4. Don't use raw email as user ID in event payloads — use a hashed or opaque identifier