| name | csharprepl-connect |
| description | Connect to a running, connector-enabled .NET process with `csharprepl connect <pid>` and evaluate C# *inside* it — read and modify its live objects, statics, and DI services, and detour live methods (#replace/#wrap). Use to debug or probe a real running app's in-memory state, not static API surface (that's dotnet-inspect) or a throwaway snippet in a fresh process (that's csharp-eval). Dev/diagnostics only — code runs with the target's full privileges, never point it at production. |
csharprepl-connect
Evaluate C# inside a separate, already-running .NET process and see/modify its live state. csharprepl
injects a real Roslyn engine into a target you launched with the connector enabled; you then send code
non-interactively (same flags and output as the local REPL) and it runs in that process against its actual
in-memory objects.
When to use this vs. csharp-eval vs. dotnet-inspect
- "What's the live state of my running app?" / "Change a method's behavior in the running process"
→ this skill (
csharprepl connect <pid>). Code runs inside the target.
- "What does this code do?" (a self-contained snippet, fresh throwaway process) → csharp-eval.
- "What does this API look like?" (signatures, members, docs — no execution) → dotnet-inspect.
The eval mechanics here — -e / --eval-file, piped stdin, quoting, -r "nuget: ...", the clean-stdout /
errors-to-stderr / nonzero-exit contract — are identical to csharp-eval; see that skill for those
details. This skill covers only what's different about connecting to a live process.
⚠️ Safety
Evaluated code runs with the target process's full privileges — it's RCE-equivalent for same-user code.
Only connect to a process for development/diagnostics.
