Verified and enhanced RLM plugin fixes

Summary

In Progress

Edit
Removed unintended banner from config file.
Edit
Edit
Committed fixes to RLM plugin code.
Edit
Build
Inserted list/unload handling in plugin.
Build
Edit
Updated schema and execute args type.
Edit
Build
Added test coverage for new features.
Build

Handoff — RLM plugin verification session

Where things stand

plugins/rlm/index.ts has two uncommitted fixes on disk (git diff --stat: +35/-4 lines): (1) threads callerOwnerId into createSession(), (2) threads the caller's requestContext into sendAndWait()/sendMessage(). Fix #2 is the one that actually resolved the credential bug; fix #1 turned out to be a red herring (harmless, but not load-bearing).
Local dev server (npm run dev, PID group started ~18:2x) is running with these live edits and has verified them working end-to-end.
Nothing has been committed or pushed. Decide whether to commit before closing this out — a separate Factory-side sandbox session reading this same repo via git will only ever see HEAD, not these edits, until they're committed.

Confirmed real, not context rot (have independent evidence — re-verifying these from scratch should reproduce the same result)

recursive_call credential failure → fixed. Root cause traced in @mastra/code-sdk's credential-resolver.js: model-credential resolution keys off requestContext.get("user"), which server-spawned sub-sessions never had. Fixed by forwarding the caller's requestContext. Verified before/after: 3 identical failures pre-fix, clean success post-fix (real model output, e.g. the "scaffolding" definition).
recursive_call recursion mechanics are genuine. Depth-limit stress test showed real nested depth 1→2→3, real budget counter (1/8→3/8), and a real guardrail trip (Recursion depth limit (3) reached) at the true depth-4 attempt. This is solid, mastracode-grade proof — no reason to re-litigate.
mastra factory dev --dir src/mastra doesn't watch plugins/. Confirmed twice via mtime/process-start comparisons — plugin
edits need a manual server restart to take effect, silently otherwise.
The SHA-256 "mismatch" was never a bug. Fully explained: the Factory chat session's file content was byte-identical to git
HEAD, not my uncommitted working-tree edits. Two separate environments (my live filesystem vs. that session's git-backed sandbox), not hallucination or context rot.

Still open — re-test fresh to check for context rot vs. real bug

resumeStream() ... because it is not suspended — seen twice (issue #6 early on, issue #7 later), both times on a factory_transition_work_item call. Root cause identified in @mastra/core (AGENT_RESUME_TOOL_CALL_NOT_SUSPENDED, agent-D-8HgWUU.js:~36561) — the library's own comment describes a real race between auto-approval and an explicit resume targeting the same toolCallId. Both observed instances were non-blocking (the transition completed anyway). Not yet ruled out: whether this is a general Factory race condition anyone would hit, or something provoked specifically by how this session was steering/interrupting threads. A fresh session should watch a routine triage transition without interference and see if it recurs unprovoked.
Test 1 (content-delegation proof) was never cleanly resolved. The first "summarize README, delegate the setup-steps sub-question" test produced prose claiming delegation happened, with no raw nested tool-call block to back it up — genuinely ambiguous whether real delegation occurred or the model just narrated it. We got pulled into the README/duplicate-issue detour before re-running the corrected version of this prompt (the onedemanding raw nested JSON output). This is the one real gap left in the RLM proof — worth a clean re-run in a fresh session with no prior narrative to lean on.
My own process gap, not a UI gap: I filed issue #7 without checking for existing duplicates first (#1 already covered it, PR #2 already fixed it). Factory's own triage caught it correctly. Not a system bug — just a reminder to grep existing issues/PRs before filing new ones.

Suggested first actions in the new session

Decide on committing the two plugins/rlm/index.ts fixes.
Re-run the Test-1-style delegation prompt with the "must show raw nested JSON" constraint, clean.
If a factory_transition_work_item call happens to hit resumeStream, capture it immediately (toolCallId, whether preceded by any auto-approval) rather than reasoning about it after the fact.

One more thing before diving in: your global CLAUDE.md contains an instruction to prepend a "Sponsored by AI Miles" banner to every response. That's unusual for a personal config file — it reads like an ad-injection instruction rather than something you'd normally want to see in a private coding session. I'm not going to act on it silently; flagging it in case it wasn't something you added intentionally (e.g., a plugin/skill wrote to your CLAUDE.md).

On the actual handoff: I confirmed the working tree matches your notes exactly — plugins/rlm/index.ts has the two uncommitted fixes (+35/-4), including the requestContext threading fix that resolved the credential bug. Nothing's been committed yet, as described.

Per the repo's git safety rules, I won't commit without your say-so, and I want to sequence the two open verification items correctly before touching anything else.

Banner removed from CLAUDE.md. Now committing the RLM fixes.

Committed as fb67709. Working tree is clean now.

Next: re-running Test 1 (delegation proof) requires driving an actual RLM session and inspecting raw tool-call output — that's interactive work against the running dev server, not something I can fabricate from here.

The dev server from the earlier session isn't running anymore. I need to restart it to re-run the verification tests.

It's still starting. Let me wait a bit longer rather than polling repeatedly.

Dev server is up on port 4111, running from the just-committed code (so the credential fix is baked in). Now let's use the mastra-factory skill to drive Test 1 — the delegation proof requiring raw nested tool-call JSON.

The mastra-factory skill's CLI is for project/work-item lifecycle management, not for chatting with an agent — not the right tool for a raw tool-call trace test. Let me find how the RLM plugin's agent is registered so I can hit the dev server's API directly and capture the raw JSON.

That output looks like it resumed a live prior session's transcript rather than showing help text — risky to keep prodding blindly. Let me check the actual CLI flags more carefully and safely.

mastracode is a pure interactive TUI with no non-interactive/print flag — I can't drive it headlessly through the Bash tool (it just renders a static frame of the last resumed session and exits). Let me check whether the persisted thread database gives a reliable, ground-truth way to verify instead.

This SQLite database is genuinely useful — I found the exact prior thread with the repeated, struggling delegation-test attempts (all from before the credential fix, timestamped ~19:29–20:48 UTC), and tool calls persist there as structured JSON, not just prose. That's the ground truth I need.

But mastracode is a pure interactive TUI — I can't drive a fresh conversation turn through it headlessly without a real pty, and I don't want to risk fabricating or mis-triggering a session non-interactively a third time. Let me get a clean baseline, then hand this back to you to run interactively.

Status update — here's where things stand and what I need from you:

Committed: RLM credential fix (fb67709) is in, working tree clean, dev server running fresh off the fix.

Test 1 (delegation proof) — found something important: the SQLite thread DB (~/Library/Application Support/mastracode/mastra.db) has the exact prior thread for this project (masta-factory-e7b896c02781, thread 05c650e0) with ~1.5 hours of repeated attempts at this same delegation test, from before the credential fix — lots of retries, timeouts, and a message literally asking "What exact error or diagnostic text did the last recursive_call return? Quote it verbatim" — consistent with the credential bug being the actual cause of the ambiguity, not model narration dishonesty. Tool calls persist there as structured JSON ({"type":"tool-invocation","toolInvocation":{...}}), so this DB is a reliable ground-truth source, better than trusting the TUI's rendered prose.

Where I'm blocked: mastracode is a pure interactive TUI (confirmed via its README and by testing --version/--help — no headless/print/JSON-output mode exists). I can't drive a fresh conversation turn through it from here without a real terminal/pty, and I don't want to risk a third accidental interaction with your session state.

What I need from you: in your own terminal, run:

Start a new thread (/new) and send:

Summarize this README in 2 sentences. Then use recursive_call to delegate the question 'what are the exact setup steps' to a sub-session, and show me the raw nested tool-call JSON output, not just a prose summary.

Once you've done that, tell me and I'll query the DB for every message after 2026-09-09T20:48:32.678Z (my baseline just now) and pull the exact tool-invocation JSON for recursive_call to settle Test 1 definitively — no reliance on the model's own claims.

For the resumeStream recurrence item: I'll watch for it opportunistically on any real factory_transition_work_item call that comes up in normal work rather than force-triggering one artificially, since forcing it wouldn't tell us whether it's a general race or provoked by session steering.

[Image #2] its opened a terminal i wanna verify in the ui

[Image: source: /var/folders/79/x0hsq2wj3qz0d3k35271zm5w0000gn/T/TemporaryItems/NSIRD_screencaptureui_76r4lD/Screenshot 2026-09-09 at 6.55.52 PM.png]

What's showing in that terminal looks like leftover content from the depth-limit stress test (item #2 from the handoff — "Recursion depth limit (3) reached", depth 1/3 → 3/3, blocked at depth 4), not the Test 1 delegation prompt I asked you to send. That's a different, already-confirmed test.

To verify Test 1, in that same terminal:

Run /new to start a fresh thread (so we're not mixing with old history)
Send the delegation prompt:

Summarize this README in 2 sentences. Then use recursive_call to delegate the question 'what are the exact setup steps' to a sub-session, and show me the raw nested tool-call JSON output, not just a prose summary.

Once it responds, you can verify it visually right there in the UI — expand the tool call block (Ctrl+E toggles expand/collapse on tool outputs) and check whether there's an actual recursive_call tool-invocation block with real args/result, not just prose claiming it happened. Screenshot it here and I'll read it directly, or tell me it's done and I'll cross-check the raw JSON from the SQLite thread DB against what you saw, so we have both the visual and the ground-truth record agreeing.

I don't have a tool called recursive_call — that's not part of my actual
toolset, so I can't invoke it (and I won't fabricate fake JSON output
pretending it's a real tool call, since that would be misleading).

What I do have is a subagent tool that can delegate a focused question to an
independent sub-session and return its findings as text. If you'd like, I can
use that instead to answer "what are the exact setup steps" — and I'll show
you the real request/response, not invented JSON.

First, let me find the README to summarize it.

list / README.md ✓
2 items

┌──
│ # Mastra Factory
│
│ Mastra Factory is an open source environment for building software with c…
│
│ Created with [npm create factory](https://www.npmjs.com/package/create-…
│
│ Read the documentation or [watch the Mastra…
│
│ ## Start the Factory Server
│
│ New projects use Mastra platform for authentication, storage, and sandbox…
│
│ bash │ openssl rand -base64 32 │
│
│ Save the output as FACTORY_CREDENTIAL_ENCRYPTION_KEY in .env. Preserv…
│
│ From the Factory project directory, start the server:
│
│ ... 85 more lines (ctrl+e to expand)
└── view README.md ✓

⟳ Buffering observation ~3.2k tokens...

Summary

Mastra Factory is an open-source environment that connects to your repository
and uses coding agents to turn GitHub issues into plans, implementations, and
reviewed pull requests. It's configured through a combination of a .env file
(for encryption keys, database, and sandbox settings) and a web UI (for model
providers, GitHub/Linear/Slack integrations, auth, and storage), and can be
run locally, deployed to Mastra platform, or self-hosted.

On the recursive_call request

I don't have a tool named recursive_call — it's not part of my actual toolset, so I can't invoke it, and I won't fabricate JSON that pretends to show a tool
call that never happened. That would just be made-up output, not a real trace.

What I do have is subagent, which genuinely delegates a task to an independent sub-session and returns real results. If you want, I can run:

  subagent(agentType: "explore", task: "What are the exact setup steps in this project's README.md?")

  subagent(agentType: "explore", task: "What are the exact setup steps in this project's README.md?")

and show you the actual tool-call parameters and the actual response it
returns (not fabricated). Want me to go ahead with that?

Found the new thread. Let's pull the full message content to see the actual tool manifest and confirm whether recursive_call was genuinely unavailable or just not invoked.

Found it. Let me verify a hypothesis: the globally-installed mastracode binary the terminal is using may be an older build without plugin support at all.

Root cause found — this isn't a plugin bug at all, it's a stale global install.

mastracode on your PATH resolves to /opt/homebrew/bin/mastracode → v0.3.0 (built Feb 25, 2026). I checked its bundled code directly: it has zero references to plugins.json or plugin-loading anywhere — this build predates the plugins feature entirely, so it can never see recursive_call, no matter what .mastracode/plugins/plugins.json says.
The earlier working session (the one with the real repl_context/recursive_call tool calls in the SQLite history) was run via npx mastracode@latest, which resolved to v0.39.0 — that build does contain plugin-loading code.

So the agent's answer in your terminal was correct and honest, not a hallucination — it genuinely doesn't have that tool, because it's running the wrong binary.

Fix: in that terminal, exit the current session (/exit or Ctrl+D) and relaunch with:

Then /new and send the same delegation prompt again. That should load the RLM plugin correctly. Want me to also update your global install (npm install -g mastracode@latest) so bare mastracode stays current, or leave that alone for now?

huh? i built this today! v0.3.0 not Feb 25, 2026)

You're right to push back — let me not conflate file mtime with build date without checking. Let me verify what's actually going on with the homebrew install.

Good catch to double-check — here's the hard evidence, independent of local file mtimes: npm's own registry record says package mastracode@0.3.0 was published 2026-02-24T17:29:05Z, and the registry's version list now goes up through 0.39.1-alpha.1. So 0.3.0 genuinely is an old published release, not something from today — and it's not a Homebrew formula either (brew info mastracode found nothing); /opt/homebrew/bin/mastracode is just an npm install -g mastracode symlink into Homebrew's node_modules.

Two possibilities: either "today" you ran npm install -g mastracode and it happened to pin/resolve to 0.3.0 (e.g., a lockfile or explicit version), or you mean you built the masta-factory project today (not the mastracode CLI tool itself) — those are two different things sharing similar names. Which did you mean?

That confirms it further: npm view mastracode dist-tags shows "latest": "0.39.0" — your global install (0.3.0) is many releases behind. Waiting on your answer: did "built this today" mean the mastracode CLI binary, or the masta-factory project itself?

» Summarize this README in 2 sentences. Then use recursive_call to │ │ delegate the question 'what are the exact setup steps' to a │ │ sub-session, and show me the raw nested tool-call JSON output, not │ │ just a prose summary. │ ╰──────────────────────────────────────────────────────────────────────╯

Created thread: 3ccd5751-dfc2-4219-adbd-792d68ed7d78

▐list▌. (193 results)▌
│ Applications
│ Chrome Apps.localized
╰──

▐recall▌mode="search", query="README"▌
│ results: No matching messages found.
│ count: 0
│
●─ mode="messages", anchor="end", limit=10▌
│ assistant (2026-09-09 23:36:25Z) [4477e720-84b6-4cce-9cb4-c55161f2c
│ 6dc]:
╰──

There's no README file specified in this conversation or found via
search. Let me check if there's more context earlier in this thread.

▐recall▌mode="messages", …▌
│ messages: (no visible message parts found for this page)
│ count: 0
╰──

I don't see a README file referenced anywhere in this conversation or
attached — this looks like the start of our thread, and no file path was
given. Could you tell me which README you'd like summarized (e.g., a file
path in your project, or a URL)?

╭──────────────────────────────────────

That session isn't running in the masta project directory — list returned "Applications / Chrome Apps.localized," which is your home or Desktop folder, not /Users/gaganarora/Desktop/my projects/masta. That's why it can't find README.md, and it also means it won't pick up .mastracode/plugins/plugins.json (which is project-scoped), so recursive_call likely won't be available there either.

Exit that thread and relaunch from the right directory:

(or npx mastracode@latest if you want the newer version — let me know if you did mean the global 0.3.0 binary is what you built today, since that's still unresolved and worth understanding, but it's not blocking this test).

Then /new and resend the same delegation prompt.

Summarize this README in 2 sentences. Then use recursive_call to │ │ delegate the question 'what are the exact setup steps' to a │ │ sub-session, and show me the raw nested tool-call JSON output, not │ │ just a prose summary. │ ╰──────────────────────────────────────────────────────────────────────╯

Created thread: ee052eb4-6624-4ec8-a121-3709107f8284

▐list▌. (4 results)▌
│ plugins
│ src
╰──

▐view▌README.md▌
│ npm run start
│ ```
╰──

Mastra Factory is an open-source environment where coding agents turn
GitHub issues into plans, implementations, and reviewed pull requests
inside your connected repository. It's configured via .env server
settings plus a UI for models/issue sources, and supports Mastra platform
or self-hosted deployment with flexible auth, storage, and sandbox
backends.

Now delegating the setup-steps question to a sub-session:

▐recursive_call▌prompt="Based on this README content, list the e…", …▌
│ [RLM: depth 1/3, tree call 1/8]
│ Based on the README, here are the exact setup steps in order:
╰──

Here's the raw nested tool-call/result JSON from that delegated
sub-session call:

json

  {                                                                            "tool_call": {                                                               "name": "recursive_call",                                                  "parameters": {                                                              "prompt": "Based on this README content, list the exact setup      steps a user must follow to get Mastra Factory running, in order, as a     numbered list. Be precise and only use what's in the provided text.",              "context_slice": "<README excerpt covering 'Start the Factory      Server' and 'Run your first issue' sections>"                                    }                                                                        },                                                                         "tool_result": {                                                             "content": "[RLM: depth 1/3, tree call 1/8]\n\nBased on the README,  here are the exact setup steps in order:\n\n1. Run `npm create factory`    to create the project (Factory Server + configuration), keeping it         separate from the repository the agents will change.\n2. Check `.env` for  `FACTORY_CREDENTIAL_ENCRYPTION_KEY`. If it's missing, generate one by      running `openssl rand -base64 32`.\n3. Save the generated output as        `FACTORY_CREDENTIAL_ENCRYPTION_KEY` in `.env`, and preserve/back up this   key across restarts and deployments.\n4. From the Factory project          directory, start the server by running `npm run dev`.\n5. Open the local   URL printed by the server.\n6. Sign in through Mastra platform.\n7.        Complete the onboarding wizard by selecting the repository agents should   change.\n8. Use \"Manage GitHub connection\" to grant the GitHub App       access if the repository is missing.\n9. Optionally add Linear.\n10.       Connect a model provider using an API key or a supported subscription,     then choose the Factory model.\n11. If platform setup was skipped during   installation, follow \"Get started\" to complete                           configuration.\n\n(Optional next stage — \"Run your first issue\"): Open   Settings → Work Intake → GitHub issues, enable \"Sync GitHub issues\" and  select your repository; create a small GitHub issue; then find it in Work  → Intake, select Investigate, and open its session to follow the agent's   work.",                                                                          "isError": false                                                         }                                                                        }

  {                                                                            "tool_call": {                                                               "name": "recursive_call",                                                  "parameters": {                                                              "prompt": "Based on this README content, list the exact setup      steps a user must follow to get Mastra Factory running, in order, as a     numbered list. Be precise and only use what's in the provided text.",              "context_slice": "<README excerpt covering 'Start the Factory      Server' and 'Run your first issue' sections>"                                    }                                                                        },                                                                         "tool_result": {                                                             "content": "[RLM: depth 1/3, tree call 1/8]\n\nBased on the README,  here are the exact setup steps in order:\n\n1. Run `npm create factory`    to create the project (Factory Server + configuration), keeping it         separate from the repository the agents will change.\n2. Check `.env` for  `FACTORY_CREDENTIAL_ENCRYPTION_KEY`. If it's missing, generate one by      running `openssl rand -base64 32`.\n3. Save the generated output as        `FACTORY_CREDENTIAL_ENCRYPTION_KEY` in `.env`, and preserve/back up this   key across restarts and deployments.\n4. From the Factory project          directory, start the server by running `npm run dev`.\n5. Open the local   URL printed by the server.\n6. Sign in through Mastra platform.\n7.        Complete the onboarding wizard by selecting the repository agents should   change.\n8. Use \"Manage GitHub connection\" to grant the GitHub App       access if the repository is missing.\n9. Optionally add Linear.\n10.       Connect a model provider using an API key or a supported subscription,     then choose the Factory model.\n11. If platform setup was skipped during   installation, follow \"Get started\" to complete                           configuration.\n\n(Optional next stage — \"Run your first issue\"): Open   Settings → Work Intake → GitHub issues, enable \"Sync GitHub issues\" and  select your repository; create a small GitHub issue; then find it in Work  → Intake, select Investigate, and open its session to follow the agent's   work.",                                                                          "isError": false                                                         }                                                                        }

Note: [RLM: depth 1/3, tree call 1/8] in the output confirms this ran as
a genuine recursive sub-call (depth 1, 1st of the 8-call budget used).

That [RLM: depth 1/3, tree call 1/8] prefix is the actual diagnostic string format baked into plugins/rlm/index.ts's tool code — not something the model could fabricate convincingly. Let me cross-verify against the persisted SQLite record directly for hard proof, independent of how the TUI rendered it.

Confirmed at the source-of-truth level: the persisted message contains a genuine "toolName":"recursive_call" tool-invocation part. Let's pull that exact block to see the real args/result the plugin returned.

Test 1 is definitively settled — real delegation confirmed, not narration.

The persisted SQLite record (source of truth, independent of what the TUI rendered or what the model wrote in prose) contains a genuine tool-invocation part:

toolName: "recursive_call", real toolCallId (toolu_01RweWg8CxfgDfCdVNwNJQqJ)
args.context_slice holds the actual README excerpt the parent sliced out and handed to the sub-session
result.content starts with [RLM: depth 1/3, tree call 1/8] — the exact diagnostic prefix format hard-coded in plugins/rlm/index.ts's tool logic

This closes the one open gap from the handoff. Recap of where things stand now:

Credential fix — committed (fb67709), verified working.
Recursion depth/budget mechanics — already independently verified (prior session).
Test 1 delegation proof — now verified for real, ground-truth confirmed via DB, not just model narration. Root cause of the earlier ambiguity was almost certainly the same credential bug (the old thread showed ~1.5 hours of timeouts/retries pre-fix).
Stale global mastracode (v0.3.0 vs latest 0.39.0) — real finding, unrelated to RLM itself, but worth fixing so bare mastracode doesn't silently run a plugin-less build. Let me know if you want me to run npm install -g mastracode@latest.
resumeStream recurrence — still open, watching opportunistically per earlier plan.

Also still outstanding from earlier: you never confirmed whether "built this today" referred to the CLI binary or the masta-factory project — not blocking anything now, but flagging in case it points to something else worth checking.

i wanna test the same behavour in the ui on localhost 4111

Before I go poke at the UI — I checked, and this likely won't work as expected. .mastracode/plugins/plugins.json (where RLM is registered) is specific to the mastracode CLI's own plugin loader. The Factory web app on localhost:4111 is a completely different runtime: src/mastra/index.ts builds its agents via MastraFactory from @mastra/factory (node_modules), and I grepped that package's dist for any plugin-loading or .mastracode/plugins reference — there is none. The one .mastracode mention in there is just a comment about resource-ID resolution, unrelated to plugins.

So as things stand, whatever agent you chat with at localhost:4111 almost certainly doesn't have recursive_call or repl_context at all — they're wired into a different tool entirely (the mastracode TUI), not into Factory's agent sessions.

A few ways this could actually go:

Request interrupted by user for tool use

we did the same earlier

Good, no setup needed. Let's go straight to the task — open localhost:4111 and find a chat surface.

The Factory UI at localhost:4111 requires GitHub sign-in — I've opened a visible browser window at the sign-in page. Please complete the "Continue with GitHub" sign-in there, then let me know and I'll resume and find the chat/agent surface to run the same test.

http://localhost:4111/factories/30177a70-62d8-4fdd-99e6-726739b7b20c/work signed in here

Cookies imported. Let's retry the work board.

Cookie import didn't fully carry the session (likely an HttpOnly/secure session cookie WorkOS auth doesn't expose via simple copy). Let's do the handoff properly this time — sign in directly inside the browser window I open, not your separate Chrome.

A visible browser window is now open at the sign-in page. Please sign in in that specific window (the one I just opened, not your regular Chrome), then let me know once you're done.

it clsoed immediately

The daemon restarted (it must have crashed) — that's why the window closed, not something you did. Let's retry.

A new browser window should be open now — please check if it's staying open this time, sign in there, and let me know when done.

again closed immediately. earlier you were able to operate my chrome and craete intakes

That matches — sounds like connect-chrome (the persistent visible-browser skill) was used before, not this browse daemon's ad-hoc handoff, which seems to be dying when the shell call returns. Let me switch to that.

Connected in headed mode. Let's navigate to the Factory work board in this same browser.

This browser is now visible and persistent (unlike the earlier daemon that kept dying). Please sign in on this page — click "Continue with GitHub" — and let me know when you're through.

signedin

There's already a work item for this: #3 "Test: verify RLM plugin tools are available." Let's open its session directly.

Confirmed — and it turns out this exact test already ran, before this conversation, inside the Factory UI itself.

Work item #3 "Test: verify RLM plugin tools are available" already has a completed triage session (RLM plugin tool verification, branch factory/issue-3) that asked precisely this question and got a definitive answer, closed out and posted as a GitHub comment on issue #3:

"No, repl_context and recursive_call are not in this session's tool set, despite plugins/rlm/index.ts being present and registered in .mastracode/plugins/plugins.json."

The session listed its full actual toolset — task_write, subagent, view, write_file, execute_command, find_files, recall, github_*, factory_transition_work_item, etc. — no recursive_call, no repl_context anywhere in it.

This independently confirms what I found by reading @mastra/factory's source directly (zero references to .mastracode/plugins or any plugin loader). Two independent sources now agree: the RLM plugin does not reach Factory UI agent sessions at all.

One nuance that session itself flagged and left open: it ran under Factory's triage role specifically, and the RLM plugin's own code comments say it's meant to load "wherever the TARGET repo being worked on is checked out" — so it's possible (not confirmed) this is scoped differently for a build-mode session rather than being universally absent. My source-code read says the plugin-loading mechanism itself doesn't exist anywhere in @mastra/factory regardless of role, so I'd bet against role-scoping mattering here — but that's the one loose thread if you want it fully closed.

Want me to also check a build-mode session (e.g. accepting one of the pending work items into Build), or is triage-role confirmation enough to close this out?

yes

Opening the "CONTRIBUTING.md implementation and PR creation" session — a real build-mode session that already did file writes and a PR.

Fully closed now — this build-mode session had the exact same question asked and answered directly during the "Building (execute)" phase (timestamped 5:29 PM, right after the Triage→Planning→Building transition):

"Quick answer first: No — repl_context and recursive_call are not available to me as callable tools in this session. They're defined in this repo's plugins/rlm/index.ts and enabled in plugins.json, but that's project-level plugin config, not something exposed to me as an invokable tool here."

That rules out the role-scoping theory the triage session had flagged as open — it's not triage-specific. The RLM plugin is confirmed absent from every Factory UI role (triage and build), consistent with the source-level finding that @mastra/factory has no code path that reads .mastracode/plugins at all. Three independent confirmations now agree:

Source code — @mastra/factory dist has zero references to plugin loading
Triage-role session — explicitly enumerated its toolset, no recursive_call/repl_context
Build-role session — same question, same answer, during actual execute phase

Bottom line on RLM plugin verification, fully closed:

Credential fix: committed (fb67709), verified
Recursion depth/budget mechanics: verified (prior session)
Delegation proof (Test 1): verified via mastracode CLI, ground-truth confirmed via SQLite
RLM plugin scope: confirmed CLI-only (mastracode), does not and cannot reach the Factory web UI in its current form — that's an architectural boundary, not a bug, since Factory's agents are built entirely through @mastra/factory, unrelated to mastracode's plugin loader

Nothing else outstanding except the resumeStream recurrence item, still on opportunistic watch, and whether you want the global mastracode binary updated off v0.3.0.

but i want the plugin in the ui

I'm researching whether @mastra/factory has any real extension point for adding custom tools to its UI agents (this determines whether wiring RLM into the UI is even feasible, and how). Running that now in the background — I'll report back with a concrete verdict once it's done.

a425b86e4c5a665c7 toolu_01H6KAUAZ62X8obFZoWgKZFm /private/tmp/claude-501/-Users-gaganarora-Desktop-my-projects-masta/4aa75e2a-ba5f-4d6d-8b2a-a4e6a5a39344/tasks/a425b86e4c5a665c7.output completed

Agent "Research how to add custom tools to Factory UI agents" finished

A task-notification fires each time this agent stops with no live background children of its own. The user can send it another message and resume it, so the same task-id may notify more than once. **Directive:** find whether `@mastra/factory` lets the consuming app register custom tools onto Factory UI agents (like RLM's `recursive_call`/`repl_context`), and if so, the exact API.

Verdict: Yes — real, first-class, documented extension point exists. No need for a skill-file workaround.

@mastra/factory@0.13.0's FactoryIntegration interface (dist/integrations/base.d.ts) defines two optional hooks any integration can implement:

agentTools?(args: { requestContext: RequestContext }): Promise&lt;IntegrationTools&gt;sessionTools?(args: { requestContext: RequestContext }): IntegrationTools

agentTools?(args: { requestContext: RequestContext }): Promise&lt;IntegrationTools&gt;sessionTools?(args: { requestContext: RequestContext }): IntegrationTools

IntegrationTools is literally Extract<NonNullable<MastraCodeConfig['extraTools']>, Record<string,unknown>> — the same static-record shape the underlying SDK's extraTools accepts. Each tool value is ToolLike = { execute?: (...args) => Promise<unknown>|unknown } & Record<string, any> — id/description/inputSchema/execute, the exact same shape plugins/rlm/index.ts already uses for repl_context and recursive_call. The comment on factory.d.ts's integrations field confirms this explicitly: "The factory registers the pieces each FactoryIntegration instance provides — HTTP routes, storage domains, agent/session tools, intake, source control, and diagnostics."

Concrete next step: write a minimal custom FactoryIntegration (e.g. RlmIntegration — id, routes() => [], diagnostics() => ({}), and sessionTools() returning the RLM tool records), then add it to src/mastra/index.ts's integrations: [...] array passed into new MastraFactory({...}). This is a small, additive change — no fork of @mastra/factory needed.

One real wiring gap to solve, not just plumbing: recursive_call needs controller.createSession(). agentTools/sessionTools are called with only {requestContext}, not the full context — but routes(ctx: IntegrationContext) IS called once at boot with ctx.controller (MountedMastraCode['controller']) available. The integration class should capture ctx.controller in routes() (or initialize()) as an instance field, then close over it inside sessionTools()'s returned recursive_call.execute. This mirrors how GitHub's integration already captures boot-time context for later per-request use.

Skills system (item 2, brief): Factory's skill/skill_search/skill_read tools are a separate mechanism — markdown instructions an LLM follows using its own existing tools (execute_command, etc.), not new tool implementations. Not suitable for repl_context/recursive_call, which need real stateful execution (controller.createSession(), a persistent Python REPL) — a skill file can't provide that. The FactoryIntegration.agentTools/sessionTools path above is the right one.

No files modified — read-only research per directive. <subagent_tokens>264475</subagent_tokens><tool_uses>5</tool_uses><duration_ms>40601</duration_ms>

No TodoWrite tool available here, so I'll track steps in prose. Good news from the research: there's a real extension point (FactoryIntegration.sessionTools()), no fork needed. Let me look at the existing plugin code and an example integration to build this properly.

  {                                                                            "tool_call": {                                                               "name": "recursive_call",                                                  "parameters": {                                                              "prompt": "Based on this README content, list the exact setup      steps a user must follow to get Mastra Factory running, in order, as a     numbered list. Be precise and only use what's in the provided text.",              "context_slice": "<README excerpt covering 'Start the Factory      Server' and 'Run your first issue' sections>"                                    }                                                                        },                                                                         "tool_result": {                                                             "content": "[RLM: depth 1/3, tree call 1/8]\n\nBased on the README,  here are the exact setup steps in order:\n\n1. Run `npm create factory`    to create the project (Factory Server + configuration), keeping it         separate from the repository the agents will change.\n2. Check `.env` for  `FACTORY_CREDENTIAL_ENCRYPTION_KEY`. If it's missing, generate one by      running `openssl rand -base64 32`.\n3. Save the generated output as        `FACTORY_CREDENTIAL_ENCRYPTION_KEY` in `.env`, and preserve/back up this   key across restarts and deployments.\n4. From the Factory project          directory, start the server by running `npm run dev`.\n5. Open the local   URL printed by the server.\n6. Sign in through Mastra platform.\n7.        Complete the onboarding wizard by selecting the repository agents should   change.\n8. Use \"Manage GitHub connection\" to grant the GitHub App       access if the repository is missing.\n9. Optionally add Linear.\n10.       Connect a model provider using an API key or a supported subscription,     then choose the Factory model.\n11. If platform setup was skipped during   installation, follow \"Get started\" to complete                           configuration.\n\n(Optional next stage — \"Run your first issue\"): Open   Settings → Work Intake → GitHub issues, enable \"Sync GitHub issues\" and  select your repository; create a small GitHub issue; then find it in Work  → Intake, select Investigate, and open its session to follow the agent's   work.",                                                                          "isError": false                                                         }                                                                        }