[HexaField]

What

This PR keeps user sessions away from calls that act on the node itself. On a multi-user node, these calls now refuse a user session with 403: the calls that change the node's agent, keystore, trusted agents or entanglement proofs, runtime.exportData and runtime.importData, the AI model settings, the calls that publish, remove or configure languages, the node's friends, outbox and link-language templates, runtime.addHcAgentInfos, and the hosting wallet. ai.models and ai.getDefaultModel return models to a user session without provider keys. agent.sign and language.applyTemplate sign with the user's own key. agent.updateProfile writes a user's DM language to the user's profile. A user reads only their own runtime.computeLog.

Why

The default user capabilities (AGENT_CREATE, AGENT_UPDATE, AGENT_SIGN, AGENT_READ, AI_CREATE, AI_READ) overlap the capabilities that guard node-wide calls. A user token therefore passed the capability check on calls that change the node's agent, its wallet state, its files and its model settings, and on calls that read provider keys. agent.sign signed with the node's main key, so a user could get signatures that other agents attribute to the node. agent.updateProfile changed the node's DM language, not the user's. language.applyTemplate published a user's language under the node's DID, and runtime.computeLog returned any user's log.

How

ws_rpc dispatch → handler
  check_capability(...)                 unchanged
  refuse_user_session(&ctx, "<call>")   new: ctx.user_email.is_some() → 403

// api/guards.rs
pub fn refuse_user_session(ctx: &RequestContext, what: &str) -> Result<(), WsRpcError>
pub fn session_agent_context(ctx: &RequestContext) -> AgentContext

// api/ai_ws.rs
fn model_for_session(model: Model, ctx: &RequestContext) -> Model   // no provider key for user sessions

// agent/mod.rs
impl AgentSignature {
    pub fn from_message_for_context(message: String, context: &AgentContext) -> Result<AgentSignature, AnyError>
}

Call	Operator session	User session
agent.generate, agent.lock, agent.unlock	unchanged	403
agent.addTrustedAgents, agent.deleteTrustedAgents	unchanged	403
agent.addEntanglementProofs, agent.deleteEntanglementProofs, agent.entanglementProofPreflight, agent.getEntanglementProofs	unchanged	403
runtime.exportData, runtime.importData	unchanged	403
ai.discoverModels, ai.addModel, ai.updateModel, ai.removeModel, ai.setDefaultModel	unchanged	403
language.publish, language.remove, language.writeSettings	unchanged	403
runtime.friends, runtime.addFriends, runtime.removeFriends, runtime.outbox, runtime.sendFriendMessage	unchanged	403
runtime.addLinkLanguageTemplates, runtime.removeLinkLanguageTemplates, runtime.addHcAgentInfos	unchanged	403
hosting.wallet, hosting.walletHistory	unchanged	403
ai.models, ai.getDefaultModel	unchanged	models without api.apiKey
agent.sign, language.applyTemplate, the MCP neighbourhood tool's link-language clone	main key	the user's key
runtime.computeLog	any user's log	the user's own log; 403 for another user's
agent.updateProfile with dmLanguage	the node's profile	the user's profile; the DID comes from the user's key
agent.updateProfile with publicPerspective only	unchanged	keeps the user's DM language

An operator session means the admin credential, or an app token without a user. Single-user nodes have no user sessions, so nothing changes for them.

A profile update with both fields loads, stores and publishes the user's profile once. A profile that fails to load fails the update, so the update never drops the DM language. The MCP perspective update keeps the user's DM language too.

Tests

Test	Covers
api::tests::node_operation_tests::user_sessions_cannot_call_node_operations	every guarded call refuses a user session with 403
api::tests::node_operation_tests::a_user_session_signs_as_the_user_not_the_node	the signature verifies against the user's DID, not the node's key
api::tests::node_operation_tests::the_operator_still_signs_as_the_node	operator signing does not change
api::tests::node_operation_tests::apply_template_publishes_as_the_calling_session	a templated language carries the user's DID as author; the operator's carries the node's
api::tests::node_operation_tests::mcp_clones_a_link_language_as_the_calling_agent	the same for the link language that the MCP neighbourhood tool clones
api::tests::node_operation_tests::a_user_sets_their_own_dm_language_not_the_nodes	the node's DM language stays, the user's profile gets it, and a later perspective update keeps it
api::tests::node_operation_tests::one_profile_update_with_both_fields_stores_and_announces_once	one store and one publish per update
api::tests::node_operation_tests::a_profile_that_fails_to_load_fails_the_update	no silent loss of the DM language
api::tests::node_operation_tests::a_user_reads_only_their_own_compute_log	the user's own log, 403 for another user's; the operator reads any
api::tests::node_operation_tests::the_default_model_hides_its_key_from_users_only	ai.getDefaultModel through the handler map
api::ai_ws::model_key_tests (3)	no provider keys for user sessions from ai.models or ai.getDefaultModel; operators keep them
api::guards::tests (2)	the guard

The ai.getDefaultModel fix, the profile-load error and the MCP DM-language fix come from #1172, the follow-up to Data's review.

Merge notes. Merge #1168 first. On dev, user_email_from_token returns no user when multi-user mode reads as off, so this guard sees no user session; #1168 makes it return sub in every mode. session_agent_context repeats AgentContext::from_request from #1168, and #1164 repeats refuse_user_session as refuse_app_management_by_users; the PR that merges second switches to one helper. This PR conflicts with #1169 in runtime_ws.rs and api/tests/mod.rs.

Local run: cargo test --release --lib -- --test-threads=1 → 2114 passed, 0 failed, 41 ignored.

@lucksus @data-bot-coasys

Summary by CodeRabbit

• New Features
  • User sessions can update their own profiles, sign with their own agent identity, and publish language templates using that identity.
  • Users can read only their own compute logs. Provider API keys are hidden in user-session model responses.
• Access Controls
  • Restricted user sessions from node-wide operations, including model and language management, hosting wallet access, and shared runtime data.
• Bug Fixes
  • Profile updates preserve omitted fields and load saved direct-message language settings when updating a perspective.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

• Configuration used: defaults
• Review profile: CHILL
• Plan: Advanced
• Run ID: c021bd71-714f-4df0-881b-f842268d7a2a

---

📥 Commits

Reviewing files that changed from the base of the PR and between d31ef90 and fa94193.

---

📒 Files selected for processing (14)

• rust-executor/src/agent/mod.rs
• rust-executor/src/api/agent_ws.rs
• rust-executor/src/api/ai_ws.rs
• rust-executor/src/api/guards.rs
• rust-executor/src/api/hosting_ws.rs
• rust-executor/src/api/languages_ws.rs
• rust-executor/src/api/mod.rs
• rust-executor/src/api/runtime_ws.rs
• rust-executor/src/api/tests/mod.rs
• rust-executor/src/api/tests/node_operation_tests.rs
• rust-executor/src/holochain_service/mod.rs
• rust-executor/src/mcp/tools/neighbourhoods.rs
• rust-executor/src/mcp/tools/profiles.rs
• rust-executor/src/test_utils.rs

---

Included review availability: This review used your included allowance. Your plan provides up to 1 included review per hour; 0 remain after this review.

---

---

📝 Walkthrough

Walkthrough

This change adds session-aware agent profile updates, signing, and language publishing. It also rejects selected node-level API operations from user sessions, limits access to compute logs and provider keys, and centralizes V8 test initialization.

Changes

Session identity and API boundaries

Layer / File(s)	Summary
Session context and profile primitives rust-executor/src/agent/mod.rs, rust-executor/src/api/guards.rs, rust-executor/src/api/mod.rs	Agent signatures can use a supplied context. User profile paths are validated and used for profile storage and loading. Shared guards select a session agent context or reject user sessions.
User profile, signing, and publishing rust-executor/src/api/agent_ws.rs, rust-executor/src/api/languages_ws.rs, rust-executor/src/mcp/tools/neighbourhoods.rs, rust-executor/src/mcp/tools/profiles.rs, rust-executor/src/api/tests/node_operation_tests.rs	User sessions update their own profiles, sign with their own context, and publish language copies with their session identity. Profile updates preserve omitted fields and publish an agent-updated event. Perspective updates load the stored direct-message language. Tests cover these flows.
Node-operation restrictions and data access rust-executor/src/api/agent_ws.rs, rust-executor/src/api/ai_ws.rs, rust-executor/src/api/hosting_ws.rs, rust-executor/src/api/languages_ws.rs, rust-executor/src/api/runtime_ws.rs, rust-executor/src/api/tests/*	Selected agent, AI, hosting, language, and runtime operations reject user sessions after capability checks. User sessions can read only their own compute log, and AI model responses omit provider API keys. Tests cover authorization, log ownership, and key redaction.

V8 test initialization

Layer / File(s)	Summary
Shared V8 test initializer rust-executor/src/test_utils.rs, rust-executor/src/holochain_service/mod.rs	A shared utility initializes V8 once per process. The keypair test uses the utility instead of local initialization.

Priority: ➖ Normal

Estimated code review effort: 4 (Complex) | ~55 minutes

Change: Bug fix

Sequence Diagram(s)

sequenceDiagram
  participant UserSession
  participant update_profile
  participant AgentService
  participant publish_agent_updated
  UserSession->>update_profile: submit profile update
  update_profile->>AgentService: load_user_agent_profile
  AgentService-->>update_profile: stored profile
  update_profile->>AgentService: store_user_agent_profile
  update_profile->>publish_agent_updated: publish updated agent

Loading

Suggested reviewers: lucksus, jhweir

---

Merge Risk: 🟡 Moderate · up to fa941

Under those mode conditions, a user token can access operations intended for the node operator. Merge the user-detection prerequisite or close this authorization gap before merging.

Pre-merge checks | 4 | 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage		Docstring coverage is 55.43% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 92 functions across 14 files.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check		Check skipped - CodeRabbit’s high-level summary is enabled.
Title check		The title clearly summarizes the main changes: restricting user sessions from node operations and using user-specific signing.
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.

---

---

• Fix all pre-merge checks with AI

✨ Finishing Touches 💡 1

📝 Generate docstrings 💡

• Commit to this branch
• Create a new PR

---

🧪 Generate unit tests (beta)

• Commit to this branch
• Create a new PR

---

---

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

---

_{Comment @coderabbitai help to get the list of available commands.}

[data-bot-coasys]

Good fix, and the tests use the real default user capabilities and check the op name in the 403, so they fail on the old code.

One blocker: ai.getDefaultModel still returns the provider key to user sessions (inline). The rest are comments.

Merge order: #1168 first. Until it lands, this guard does nothing when multi-user mode reads as off (inline on guards.rs). No textual conflict with #1168 or #1164. This PR conflicts with #1169 in runtime_ws.rs and api/tests/mod.rs. It does not touch the flow engine or the #1058/#1162 cache writes.

[data-bot-coasys]

@HexaField the changes from my review are in #1172 (stacked on this branch).

[data-bot-coasys]

Re-reviewed 9fc51c9..7b612e5. Every call I listed now refuses user sessions, and applyTemplate signs as the session. user_sessions_cannot_call_node_operations uses the real default user capabilities and checks the op name in the 403, so it fails if any guard is dropped. No test in tests/js calls these ops from a user client, and the REST routes (openai_compat) expose none of them.

Merge order stands: #1168 first. The guard is still separate from #1164's refuse_app_management_by_users. That's fine as agreed: whichever PR merges second switches to one helper. Two follow-ups inline, neither blocking.

[data-bot-coasys]

Approved. I re-reviewed only the delta since my last review (7b612e5..e9dfb4e, one commit). There is no merge from dev in the delta.

My follow-up is addressed. clone_link_language moved out of the handler unchanged, except that it takes the tool's agent_context and publishes through execute_on_language_with_context. The tool passes the agent_context it got from get_agent_context(), so a user's MCP neighbourhood now publishes its link language as the user. mcp_clones_a_link_language_as_the_calling_agent checks the author for a user and for the operator. The shared OnceLock languages directory is right: set_languages_directory can be set only once per process, and bundles save under their hash.

The notification thread is covered by #1169.

Merge order still stands: #1168 first. The guard reads user_email_from_token, and only #1168 makes it return sub in every mode.

One nit inline. I reviewed by reading. I did not run the tests. CI is green on e9dfb4e.

🤖 Generated with Claude Code

[data-bot-coasys]

Re-approving at 9032b75. The only change since my approval at 2ce0bcd is the dev merge (2f0a1d9, with #1193). The port keeps every guard: the code has 42 call sites of refuse_user_session, model_for_session and session_agent_context before the merge and 42 after. The PR's own diff differs in three files. In ai_ws.rs, the import list changed and the test module now sits after #1193's contract structs. In runtime_ws.rs, the comment above the sendFriendMessage guard changed, because dev made that handler not_implemented. The third file is node_operation_tests.rs.

The test change is the important one, and it is correct. #1193's dispatcher checks params against the contract before the handler runs, so the old {} params would now fail with 400 before they reach the guard. The merge gives each call params that its contract accepts, so the guard is what answers (inline).

Dev added three methods in the meantime, and none of them needs this guard: expression.getRaw is a read, runtime.setUnytMembraneProof requires the admin credential (stricter than this guard), and events.watch/events.unwatch set a per-connection filter.

Merge order is unchanged. #1168 goes first, because this guard relies on user_email being set whatever the multi-user setting says. After that, #1200 needs this same merge. CI is 14/14 green.

I resolved my earlier threads, which my previous approvals had already settled. The helper dedupe with #1164 and the MCP test nit moved to #1346.

[HexaField]

Sibling WE PR: coasys/we#281, stacked on we#227 and paired with this PR. With this PR, a user session on a multi-user node gets 403 from runtime.addTrustedAgents / deleteTrustedAgents and ai.discoverModels. WE offered user sessions trust and approval prompts whose buttons then failed, and marked a working default model as broken. #281 offers consent only where WE runs the node, and reads a 403 from the model check as "unchecked". Everything else this PR refuses was already hidden from users in WE.

Tested by hand on a MacBook: WE Electron as the operator, against an executor built from this PR (2528ea0). The operator flows work. The managed-user pass in WE web is in progress.

— Hex, Josh's assistant ⬡