fix(agent_prompts): anchor coding-agent prompts in action_dir, not workspace_dir (#3242)

src/openhuman/agent_registry/agents/code_executor/prompt.md

@@ -1,6 +1,6 @@
 # Code Executor — Sandboxed Developer
 
-You are the **Code Executor** agent. You write, run, and debug code in a sandboxed environment.
+You are the **Code Executor** agent. You write, run, and debug code inside the **action sandbox** — `Config.action_dir` (defaults to `~/OpenHuman/projects`; override with `OPENHUMAN_ACTION_DIR`). Your `shell` / `node_exec` / `npm_exec` / `file_write` / `edit` / `apply_patch` / `git_operations` tools default their working directory and relative-path root to this directory. **Clone repos and write build artifacts under the action sandbox.** Internal product state under `Config.workspace_dir` (memory, sessions, vault, etc.) is denied to your tools — do not try to read or write there.
 
 ## Capabilities
 

src/openhuman/agent_registry/agents/loader.rs

@@ -341,6 +341,41 @@ mod tests {
         }
     }
 
+    /// Regression guard for #3236.
+    ///
+    /// PR #3074 introduced the `Config.action_dir` / `Config.workspace_dir`
+    /// split: acting tools resolve to `action_dir` (default
+    /// `~/OpenHuman/projects`), and `workspace_dir` is reserved for
+    /// internal product state (memory / sessions / vault / etc.) that is
+    /// denied to agent tools. The coding-agent prompts must reflect that
+    /// split — saying "in a sandboxed environment" or "the workspace has
+    /// code …" without anchoring contradicts the new model and steers
+    /// the model toward paths that hit the internal-state denylist.
+    ///
+    /// If a future edit reintroduces stale phrasing, this assertion fires
+    /// at `cargo test` time before the bad prompt ships.
+    #[test]
+    fn coding_agent_prompts_reference_action_sandbox_not_stale_workspace() {
+        let code_executor = include_str!("code_executor/prompt.md");
+        assert!(
+            !code_executor.contains("sandboxed environment"),
+            "code_executor/prompt.md still says 'sandboxed environment' \
+             generically — anchor in the action sandbox path (see #3236)"
+        );
+        assert!(
+            code_executor.contains("action sandbox") || code_executor.contains("action_dir"),
+            "code_executor/prompt.md must reference the action sandbox or action_dir (see #3236)"
+        );
+
+        let planner = include_str!("planner/prompt.md");
+        assert!(
+            !planner.contains("the workspace has code"),
+            "planner/prompt.md still says 'the workspace has code …' — \
+             use 'the project tree' or similar to avoid colliding with \
+             `Config.workspace_dir` (internal product state). See #3236."
+        );
+    }
+
     #[test]
     fn every_builtin_has_a_prompt_body() {
         use crate::openhuman::context::prompt::{

src/openhuman/agent_registry/agents/planner/prompt.md

@@ -6,7 +6,7 @@ Before you plan, **gather context** so the plan is grounded in reality, not gues
 
 - Use `memory_recall` to search what we already know — past decisions, user preferences, project context, prior plans. Memory is cheap; planning blind is expensive.
 - Use `web_search_tool` when the goal involves external information you don't have — API docs, library comparisons, current best practices, pricing, compatibility matrices.
-- Use `file_read` to inspect relevant files when the workspace has code or config that constrains the plan.
+- Use `file_read` to inspect relevant files when the project tree has code or config that constrains the plan.
 
 Only produce the plan JSON **after** you have the context you need. A plan built on assumptions the memory or a quick search could have resolved is a bad plan.