feat(remote-control): add MCP server core feature

[alandtse]

Summary

Adds a new Remote Control CORE feature that hosts an embedded Model Context Protocol (MCP) server inside CommunityShaders.dll, so AI assistants (Claude Code, Cursor, Continue, etc.) can query and mutate runtime state for A/B testing and performance investigation.

• Off by default, binds to 127.0.0.1 — opt-in from the Settings UI.
• ImGui panel includes a "Copy MCP client config to clipboard" button that emits a Streamable-HTTP (MCP 2025-03-26) config snippet ready to paste into a host's mcpServers settings.
• Initial slice ships one bootstrap tool (get_state) to validate the wiring end-to-end. Subsequent commits will add list_features, get/set/toggle/reset_feature, run_abtest, capture_renderdoc, capture_screenshot.

Library choice — hkr04/cpp-mcp

Pinned to a0eb22c9. 280 stars, MIT, 2025-03-26 spec compliant including Streamable HTTP. Compared against gopher-mcp (26× larger, enterprise filter-chain arch) and peppemas/mcp_server (low activity); cpp-mcp is the right fit for an in-process server inside a game DLL.

Vendored as a git submodule under extern/cpp-mcp — same pattern we use for FidelityFX-SDK and Streamline — because cpp-mcp has no install rules (upstream PR #12 still open). Only server-side translation units are compiled; the bundled stdio/SSE client implementations are intentionally omitted.

Two non-obvious integration fixes (captured in cmake/cpp-mcp.cmake)

1. nlohmann_json ABI mismatch. cpp-mcp bundles 3.11.3, vcpkg ships 3.12.0. Both wrap their public API in an ABI-versioned inline namespace (json_abi_v3_11_3 vs json_abi_v3_12_0), so even sharing an include guard wasn't enough — cpp-mcp's TUs and our consumer TUs would emit different mangled symbols → LNK2001 on set_capabilities / register_tool. Fix: patch mcp_message.h at configure time to use <nlohmann/json.hpp> from vcpkg, writing the patched header to a build-tree mirror so the submodule stays clean.
2. winsock1/winsock2 conflict. cpp-mcp's vendored cpp-httplib pulls in <winsock2.h>; Skyrim's PCH transitively brings legacy <winsock.h> via <Windows.h>. Define _WINSOCKAPI_ on the cpp-mcp target (PUBLIC) so consumers and the PCH skip the legacy header.

Files

.gitmodules                                               +3
CMakeLists.txt                                            +2
cmake/cpp-mcp.cmake                                      +96
extern/cpp-mcp                                       (submodule pin)
features/Remote Control/CORE                              (marker)
features/Remote Control/Shaders/Features/RemoteControl.ini +2
src/Features/RemoteControl.{h,cpp}                      +302
src/Feature.cpp                                           +2  (register)
src/Globals.{h,cpp}                                       +4  (singleton wiring)

11 files, +412 / -0.

Test plan

• BuildRelease.bat ALL-WITH-AUTO-DEPLOYMENT succeeds with the feature wired in
• CommunityShaders.dll grows ~500 KB (cpp-mcp + bundled httplib code), deploys to SE + VR Data folders
• Feature appears under Core Features → Utility in the in-game menu
• Clipboard config preview renders correctly ({"mcpServers": {"community-shaders": {"type": "http", "url": "http://127.0.0.1:8910/mcp"}}})
• Connect Claude Code to the running game, confirm get_state returns frame counter
• VR build (compile-time VR preset)
• Confirm no firewall popup on first localhost bind

Follow-ups (separate PRs)

• list_features / get_feature / set_feature / toggle_feature / reset_feature tools
• run_abtest wrapping ABTestingManager
• capture_renderdoc(frames=N) and capture_screenshot() wrapping the existing triggers
• Optional: command-queue drain on the render thread for settings mutations (current implementation applies on the listener thread; safe for the bootstrap tool, but settings RPC will need synchronization)

🤖 Generated with Claude Code

Summary by CodeRabbit

• New Features
  • Remote Control: local server for monitoring/control (disabled by default). Settings to enable, choose port and bind address. Shows running status, last error, active listen address/port, copyable client config, and a connected-clients table with session info.
  • Remote tools: inspect (runtime metrics), feature (list/get/set/toggle), console (enqueue commands), capture (render/screenshot), and abtest (start/stop/status/diff).

[coderabbitai]

Warning

Rate limit exceeded

@alandtse has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 45 minutes and 26 seconds before requesting another review.

You’ve run out of usage credits. Purchase more in the billing tab.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: f8ad0843-4ef8-490a-8fc7-9c9f1a7100ba

📥 Commits

Reviewing files that changed from the base of the PR and between abc58ce and 65b7545.

📒 Files selected for processing (13)

• .gitmodules
• CMakeLists.txt
• cmake/cpp-mcp.cmake
• extern/cpp-mcp
• features/Remote Control/CORE
• features/Remote Control/Shaders/Features/RemoteControl.ini
• src/Feature.cpp
• src/Features/RemoteControl.cpp
• src/Features/RemoteControl.h
• src/Globals.cpp
• src/Globals.h
• src/State.cpp
• src/State.h

📝 Walkthrough

Walkthrough

Adds cpp-mcp as a vendored submodule and CMake integration, declares and registers a new RemoteControl feature, and implements an in-process MCP JSON-RPC server with ImGui settings, session tracking, client config generation, and multiple MCP tools.

Changes

Remote Control MCP Server Feature

Layer / File(s)	Summary
Build infrastructure and cpp-mcp integration .gitmodules, CMakeLists.txt, cmake/cpp-mcp.cmake, extern/cpp-mcp	cpp-mcp added as a Git submodule and built as a static library via CMake. The build copies/patches headers to use vcpkg's nlohmann/json.hpp, sets C++17 and MCP tuning defines, and links the library into the main target.
Feature type declaration and global registration src/Features/RemoteControl.h, src/Globals.h, src/Globals.cpp, src/Feature.cpp, features/Remote Control/Shaders/Features/RemoteControl.ini	Adds RemoteControl Feature subclass with settings and session types, forward-declares and exposes a global instance, instantiates it, registers it in Feature::GetFeatureList(), and provides INI metadata.
Server lifecycle, settings UI, and MCP tool implementations src/Features/RemoteControl.cpp	Implements singleton, ctor/dtor, Load/Reset, settings serialization, ImGui settings UI (enable, port, bind address, error/display, copy client config), BuildClientConfig(), guarded StartServer()/StopServer(), session bookkeeping, and registers MCP tools: inspect, feature, console, capture, and abtest.

Sequence Diagram

sequenceDiagram
  participant ImGui as ImGui (User)
  participant RemoteControl
  participant Server as mcp::server
  participant Client as MCP Client
  participant Runtime as Runtime State

  ImGui->>RemoteControl: Toggle enable / change settings
  RemoteControl->>Server: StartServer() / configure (host,port,tools)
  RemoteControl->>Server: RegisterTools()
  Server->>Server: run non-blocking

  Client->>Server: HTTP MCP request (tool call)
  Server->>RemoteControl: invoke tool handler (e.g., inspect)
  RemoteControl->>Runtime: query frame_count, VR status, features
  Runtime-->>RemoteControl: return state
  RemoteControl-->>Server: tool response JSON
  Server-->>Client: MCP response

Loading

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

Poem

🐰 I stitched a little server into code so neat,
Buttons to start, and ports to greet,
Tools that peek at frame and VR,
Clients connect from near and far —
The rabbit hops, the MCP hums, and bytes go tweet.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 17.65% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The pull request title accurately summarizes the main change: adding a new Remote Control feature that implements an MCP server core functionality.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch claude/cpp-mcp-remote-control

---

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 and usage tips.}

[github-actions]

No actionable suggestions for changed features.

[coderabbitai]

Actionable comments posted: 1

🧹 Nitpick comments (1)

cmake/cpp-mcp.cmake (1)

49-53: ⚡ Quick win

Add validation before include pattern replacement to prevent silent configuration failures.

The string(REPLACE) at lines 49-53 silently no-ops if the upstream include pattern changes (e.g., whitespace variations), which could silently reintroduce the ABI mismatch issue later. Since the submodule has no pinned commit in .gitmodules, a defensive pre-check is warranted.

💡 Suggested validation

 foreach(_hdr IN LISTS _cpp_mcp_headers)
     get_filename_component(_name "${_hdr}" NAME)
     file(READ "${_hdr}" _content)
     if(_name STREQUAL "mcp_message.h")
+        if(NOT _content MATCHES "`#include`[ \t]+\"json\\.hpp\"")
+            message(FATAL_ERROR
+                "cpp-mcp include pattern mismatch: mcp_message.h does not contain expected '`#include` \"json.hpp\"'. "
+                "Update cmake/cpp-mcp.cmake patch logic.")
+        endif()
-        string(REPLACE
-            "`#include` \"json.hpp\""
-            "`#include` <nlohmann/json.hpp>"
-            _content "${_content}")
+        string(REGEX REPLACE
+            "`#include`[ \t]+\"json\\.hpp\""
+            "`#include` <nlohmann/json.hpp>"
+            _content "${_content}")
     endif()
     file(WRITE "${CPP_MCP_PATCHED_INC}/${_name}" "${_content}")
 endforeach()

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@cmake/cpp-mcp.cmake` around lines 49 - 53, Before calling string(REPLACE) on
_content to swap "`#include` \"json.hpp\"" with "`#include` <nlohmann/json.hpp>",
add a validation step that searches _content for the exact include pattern
(e.g., match the literal "`#include` \"json.hpp\"" or a narrowly defined regex
accounting for common whitespace) and error-out with a clear cmake_fatal_error
(or message(FATAL_ERROR)) if the pattern is not found; this ensures the
subsequent string(REPLACE) in cmake/cpp-mcp.cmake actually modified something
and prevents silent no-ops if the upstream include format changed.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@src/Features/RemoteControl.cpp`:
- Around line 50-55: RemoteControl::LoadSettings currently accepts arbitrary
settings.bindAddress and settings.port from persisted JSON; enforce
loopback-only binding and clamp ports here and again in the server start path
(e.g., RemoteControl::Start or whatever launches the listener). Specifically,
when loading, validate settings.bindAddress is a loopback address (accept
"127.0.0.1" and "::1" or resolve/normalize and check isLoopback) and if not,
replace it with the loopback address; also validate/clamp settings.port into the
allowed range (e.g., 1–65535 or your app's allowed port range) and fall back to
the default (8910) on invalid values. Repeat the same checks right before
binding in the start/bind routine to avoid any runtime override from malicious
or stale config.

---

Nitpick comments:
In `@cmake/cpp-mcp.cmake`:
- Around line 49-53: Before calling string(REPLACE) on _content to swap
"`#include` \"json.hpp\"" with "`#include` <nlohmann/json.hpp>", add a validation
step that searches _content for the exact include pattern (e.g., match the
literal "`#include` \"json.hpp\"" or a narrowly defined regex accounting for
common whitespace) and error-out with a clear cmake_fatal_error (or
message(FATAL_ERROR)) if the pattern is not found; this ensures the subsequent
string(REPLACE) in cmake/cpp-mcp.cmake actually modified something and prevents
silent no-ops if the upstream include format changed.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 628edac9-aafb-4f5e-af00-d43cca0c2d8d

📥 Commits

Reviewing files that changed from the base of the PR and between fd20066 and ff55a22.

📒 Files selected for processing (11)

• .gitmodules
• CMakeLists.txt
• cmake/cpp-mcp.cmake
• extern/cpp-mcp
• features/Remote Control/CORE
• features/Remote Control/Shaders/Features/RemoteControl.ini
• src/Feature.cpp
• src/Features/RemoteControl.cpp
• src/Features/RemoteControl.h
• src/Globals.cpp
• src/Globals.h

[github-actions]

✅ A pre-release build is available for this PR:
Download

[Copilot]

Pull request overview

Adds a new CORE “Remote Control” feature that embeds an in-process MCP (Model Context Protocol) HTTP server inside CommunityShaders.dll, intended to let external AI/dev tools inspect and manipulate runtime state for investigation and A/B testing.

Changes:

• Adds a vendored cpp-mcp submodule and CMake integration to build/link it as a static library (including an ABI-alignment patch for nlohmann_json).
• Implements the RemoteControl feature with an ImGui settings panel, server lifecycle, session tracking, and initial MCP tool wiring.
• Wires RemoteControl into the global feature registry/singletons so it participates in the normal feature lifecycle.

Reviewed changes

Copilot reviewed 10 out of 11 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
.gitmodules	Adds extern/cpp-mcp submodule entry.
CMakeLists.txt	Includes and links the new cpp-mcp target.
cmake/cpp-mcp.cmake	Builds cpp-mcp as a static library and patches headers to align JSON ABI / avoid winsock conflicts.
features/Remote Control/CORE	Marks the feature as CORE for packaging/core detection.
features/Remote Control/Shaders/Features/RemoteControl.ini	Adds feature version metadata for auto-detected versioning.
src/Feature.cpp	Registers RemoteControl in Feature::GetFeatureList().
src/Globals.h	Declares the globals::features::remoteControl singleton.
src/Globals.cpp	Defines the RemoteControl singleton instance.
src/Features/RemoteControl.h	Declares the new RemoteControl feature class and settings/session state.
src/Features/RemoteControl.cpp	Implements server start/stop, UI, session bookkeeping, and MCP tool registration/handlers.

Comments suppressed due to low confidence (6)

src/Features/RemoteControl.cpp:905

• The console tool description tells callers to poll get_state, but there is no get_state tool in this PR (the equivalent is inspect(kind='state')). Update the description so clients don’t call a nonexistent tool.

							  "To verify a state change, poll get_state until "
							  "frame_count > enqueued_at_frame (at least one tick "
							  "elapsed), then observe via side channels: tracy "
							  "captures for perf-affecting changes, "

src/Features/RemoteControl.cpp:800

• The capture tool description references list_features, but the tool exposed here is feature(action='list'). Update the text to match the actual tool name/action so clients can follow the instructions.

							  "be attached or the in-app DLL loaded; check "
							  "list_features for RenderDoc loaded=true. Output "
							  "lands in RenderDoc's configured captures dir.\n"

src/Features/RemoteControl.cpp:292

• BuildClientConfig() produces an invalid URL when bindAddress is an IPv6 literal like ::1 (needs brackets: http://[::1]:PORT/mcp). Either bracket IPv6 literals when formatting or restrict bindAddress to IPv4/hostname values to avoid generating unusable client configs.

					{ "type", "http" },
					{ "url", std::format("http://{}:{}/mcp",
								 settings.bindAddress, settings.port) },
				} } } }

src/Features/RemoteControl.cpp:417

• The PR description says the initial slice ships only one bootstrap tool (get_state), but this implementation registers multiple tools and documents feature mutation/capture workflows. Either update the PR description to match what’s shipping, or trim this PR to just the bootstrap tool so scope matches the stated plan.

void RemoteControl::RegisterTools()
{
	// Five tools, each semantically rich. Reads vs writes vs lifecycles are
	// separated by tool; within each tool, kind/action discriminates the
	// specific operation. See agentic-renderdoc's "Why this design" notes —

src/Features/RemoteControl.cpp:567

• These tool handlers run on cpp-mcp’s listener thread, but they read/mutate global engine state and Feature instances (including Feature::loaded, settings, ABTestingManager, etc.). That introduces C++ data races with the render/game thread and can lead to crashes/undefined behavior. Marshal tool actions onto the main thread (e.g., via SKSE TaskInterface + promise/future) and only touch game/feature state from that thread.

	server->register_tool(tool,
		[this](const mcp::json& params, const std::string& session_id) -> mcp::json {
			RecordToolCall(session_id, "feature");
			const std::string action = params.value("action", std::string{});
			if (action.empty()) {

src/Features/RemoteControl.cpp:606

• feature(action='toggle') directly flips Feature::loaded. This bypasses the normal boot-time enable/disable flow and can enable features after State::SetupResources() has already run, leaving required GPU resources uninitialized. Consider restricting toggle to already-loaded features (disable-only), or implement a safe runtime enable/disable path that performs proper setup/teardown on the correct thread.

				const bool previous = target->loaded;
				target->loaded = desired;
				logger::info("Remote Control: feature(toggle, {}, {}) (was {})",
					shortName, desired, previous);

[Copilot]

Pull request overview

Copilot reviewed 10 out of 11 changed files in this pull request and generated 4 comments.

Comments suppressed due to low confidence (3)

src/Features/RemoteControl.cpp:802

• The capture tool description tells clients to check list_features for RenderDoc status, but no list_features tool is registered (feature enumeration is via feature with action='list'). This will mislead MCP clients/agents consuming the tool description; update the text to reference the actual tool/API shape.

							  "be attached or the in-app DLL loaded; check "
							  "list_features for RenderDoc loaded=true. Output "
							  "lands in RenderDoc's configured captures dir.\n"
							  "  screenshot — Lossless screenshot via the "

src/Features/RemoteControl.cpp:606

• feature(action='toggle') writes to Feature::loaded from the MCP listener thread. loaded is a plain bool that is read frequently on the render thread (e.g., Feature::ForEachLoadedFeature), so this introduces a data race/UB. This should be marshalled onto the main/render thread (e.g., via a command queue drained in State::Reset) or protected with proper synchronization (atomics + well-defined gating).

				const bool previous = target->loaded;
				target->loaded = desired;
				logger::info("Remote Control: feature(toggle, {}, {}) (was {})",

src/Features/RemoteControl.cpp:659

• feature(action='set'|'reset') calls Feature::LoadSettings / RestoreDefaultSettings directly on the MCP listener thread. Feature settings are consumed on the main/render thread, and many features touch D3D/game state during these operations, so this is a high risk for races/undefined behavior. Queue these mutations onto the main/render thread and return an acknowledgement token/status instead of mutating immediately on the listener thread.

					feature->LoadSettings(blob);
				} catch (const std::exception& e) {
					return ErrorResult("LoadSettings threw",
						{ { "shortName", shortName }, { "detail", e.what() } });
				}
				logger::info("Remote Control: feature(set, {})", shortName);
				return TextResult(mcp::json({
												{ "action", "set" },
												{ "shortName", shortName },
												{ "applied", true },
											})
						.dump());
			}
			if (action == "reset") {
				try {
					feature->RestoreDefaultSettings();
				} catch (const std::exception& e) {

[Copilot]

Pull request overview

Copilot reviewed 12 out of 13 changed files in this pull request and generated 3 comments.

Comments suppressed due to low confidence (4)

src/Features/RemoteControl.cpp:612

• feature(action='toggle') writes Feature::loaded from the MCP listener thread (target->loaded = desired). Feature::loaded is a plain bool that’s read each frame by Feature::ForEachLoadedFeature, so this introduces a cross-thread data race/UB. Queue toggles onto the main/game thread (e.g., via SKSE::GetTaskInterface()->AddTask or a render-thread command queue) and/or make the loaded flag changes synchronized (atomic or mutex-protected).

			if (action == "toggle") {
				if (!params.contains("enabled") || !params["enabled"].is_boolean()) {
					return ErrorResult("missing required boolean parameter 'enabled'");
				}
				const bool desired = params["enabled"].get<bool>();
				// FindFeatureByShortName filters on loaded==true so it can't
				// help re-enable; walk the full list ourselves.
				Feature* target = nullptr;
				for (auto* f : Feature::GetFeatureList()) {
					if (f->GetShortName() == shortName) {
						target = f;
						break;
					}
				}
				if (!target) {
					return ErrorResult("feature not found",
						{ { "shortName", shortName } });
				}
				const bool previous = target->loaded;
				target->loaded = desired;
				logger::info("Remote Control: feature(toggle, {}, {}) (was {})",
					shortName, desired, previous);
				return TextResult(mcp::json({

src/Features/RemoteControl.cpp:652

• feature(action='set') calls Feature::LoadSettings directly from the MCP listener thread. Many features’ LoadSettings paths are assumed to run on the main thread during config load/UI interaction and may touch shared state; invoking them off-thread risks races with the render loop. Consider marshaling settings mutations onto the main/game thread (similar to the console tool) and returning an acknowledgment once enqueued/applied.

			if (action == "set") {
				if (!params.contains("settings") || !params["settings"].is_object()) {
					return ErrorResult("missing required object parameter 'settings'");
				}
				::json blob;
				try {
					blob = ::json::parse(params["settings"].dump());
				} catch (const std::exception& e) {
					return ErrorResult("settings is not valid JSON",
						{ { "detail", e.what() } });
				}
				try {
					feature->LoadSettings(blob);
				} catch (const std::exception& e) {
					return ErrorResult("LoadSettings threw",
						{ { "shortName", shortName }, { "detail", e.what() } });
				}
				logger::info("Remote Control: feature(set, {})", shortName);

src/Features/RemoteControl.cpp:668

• feature(action='reset') calls Feature::RestoreDefaultSettings() from the MCP listener thread. Restore paths can recreate resources / mutate global state and are typically not thread-safe relative to the render loop. Please enqueue this work onto the main/game thread (or a dedicated render-thread command queue) rather than running it on the listener thread.

			if (action == "reset") {
				try {
					feature->RestoreDefaultSettings();
				} catch (const std::exception& e) {
					return ErrorResult("RestoreDefaultSettings threw",
						{ { "shortName", shortName }, { "detail", e.what() } });
				}
				logger::info("Remote Control: feature(reset, {})", shortName);
				return TextResult(mcp::json({

src/Features/RemoteControl.cpp:763

• The abtest tool calls ABTestingManager::Enable/Disable/SetTestInterval/ClearCachedSnapshots from the MCP listener thread. Enable()/Disable() call into globals::state->Load/LoadFromJson/SaveToJson and flip overlay settings, while ABTestingManager::Update() runs each frame; doing this off-thread risks races and inconsistent state. Queue these operations onto the main/game thread and consider returning the pre/post state once applied.

			if (action == "status") {
				return TextResult(statusBlob().dump());
			}
			if (action == "start") {
				if (params.contains("interval") && params["interval"].is_number()) {
					const auto secs = params["interval"].get<int>();
					if (secs > 0) {
						mgr->SetTestInterval(static_cast<uint32_t>(secs));
					}
				}
				mgr->Enable();
				logger::info("Remote Control: abtest(start)");
				return TextResult(statusBlob().dump());
			}
			if (action == "stop") {
				mgr->Disable();
				logger::info("Remote Control: abtest(stop)");
				return TextResult(statusBlob().dump());
			}
			if (action == "clear") {
				mgr->ClearCachedSnapshots();
				logger::info("Remote Control: abtest(clear)");
				return TextResult(statusBlob().dump());

[Copilot]

Pull request overview

Copilot reviewed 12 out of 13 changed files in this pull request and generated 9 comments.