mcp2term

# Futures ## Multi-session isolation - **Purpose:** Support per-client working directories and environment sandboxes. - **Usage:** Introduce a session manager plugin hook that allocates isolated directories and environment overlays before each command. ## Structured stdout/stderr attachments - **Purpose:** Allow downstream consumers to retrieve large outputs without flooding log streams. - **Usage:** Implement an MCP resource provider that persists outputs to temporary files and references them via resource URIs alongside streamed previews. ## Plugin discovery via entry points - **Purpose:** Simplify plugin distribution by allowing packages to register under a common entry point group. - **Usage:** Extend `PluginManager` to load entry points such as `mcp2term.plugins`, merging them with `MCP2TERM_PLUGINS` configuration. ## Ngrok metrics streaming - **Purpose:** Emit ngrok tunnel statistics and connection diagnostics to clients and plugins. - **Usage:** Add a background task to `NgrokController` that polls the ngrok administrative API and forwards aggregated metrics through the plugin registry for observability dashboards. ## Console echo customization templates - **Purpose:** Allow operators to customise the console mirroring format, destination streams, and optional persistence into structured logs. - **Usage:** Extend `ConsoleEchoListener` with configurable format strings supplied via `ServerConfig` and expose plugin hooks to replace or augment the default listener while keeping mirroring guarantees. ## Command cancellation policy plugins - **Purpose:** Allow administrators to customise which signals are sent for cancellation, define escalation strategies, and audit cancellation attempts. - **Usage:** Introduce a plugin hook invoked before `cancel_command` dispatches a signal so plugins can substitute signals, introduce grace periods, or capture metrics for observability dashboards. ## Backpressure telemetry publishing - **Purpose:** Surface client and server buffering metrics to plugins and operators for proactive health monitoring. - **Usage:** Expose the backpressure monitor state via plugin callbacks and structured metrics endpoints so dashboards can highlight when queues are building up and trigger alerts. ## Diagnostic policy plugins - **Purpose:** Allow deployments to customise how the client probes remote endpoints (for example, toggling probe methods, capturing historical availability metrics, or enforcing retry strategies) without modifying core client code. - **Usage:** Introduce a plugin hook invoked by the client before emitting startup diagnostics so plugins can adjust probe targets, provide additional context such as cached latency information, or short-circuit connection attempts during planned maintenance windows. The hook should receive the resolved endpoint URL and return a structured policy describing which probes to execute and how to present the resulting output to users. ## Interactive input policy plugins - **Purpose:** Allow operators to inspect, transform, or record interactive stdin data flowing from clients to the remote server. - **Usage:** Extend the plugin registry with hooks fired before `send_stdin` writes to subprocess pipes so plugins can redact secrets, enforce input quotas, or tee traffic into compliance archives. Policies could also modify the delivery strategy (for example, chunk sizing or encoding) without changing the core executor. ## Warning analytics dashboards - **Purpose:** Capture and aggregate warning events emitted by the server and client so operators can monitor recurring failure patterns, correlate them with infrastructure incidents, and produce proactive alerts. - **Usage:** Implement a plugin using the new warning listener hooks to forward warning metadata into an observability pipeline (for example, Prometheus or OpenTelemetry). Provide client-side adapters that subscribe to notice writers, batching warnings for long-term storage while keeping the interactive terminal output readable. Document configuration for routing warnings to dashboards and setting thresholds for alerting. ## File patch templating macros - **Purpose:** Layer higher-level diffing and templating workflows on top of the existing `manage_file` tool so complex multi-file refactors can be performed reproducibly. - **Usage:** Build on the unified diff support exposed via the new `patch` operation by layering templating DSLs, validation hooks, and preview tooling. Provide plugin hooks to validate patches, inject pre-commit checks, and broadcast file mutation events to auditing backends. ## Inline escape decoding profiles - **Purpose:** Allow operators to customise how inline `filetool` content is normalised when it contains escape sequences (for example, turning decoding off entirely or enabling additional escape rules for binary payloads). - **Usage:** Expose a plugin registration API so profiles can be installed at runtime (for example from MCP plugins) and forwarded to the client during handshake. Profiles should support validation hooks, remote capability negotiation, and documentation discovery so operators always understand which transformations are active before issuing edits. ## File operation conflict detection - **Purpose:** Detect and prevent conflicting edits when multiple clients edit the same file concurrently through the MCP tools. - **Usage:** Introduce optimistic concurrency controls to `FileEditor` that compute content hashes prior to mutation and verify they still match when applying edits. Expose the checksums through `FileOperationResult` so plugins and clients can warn operators about potential conflicts and offer auto-merge strategies. ## Client onboarding banner plugins - **Purpose:** Allow deployments to tailor the introductory message shown after connecting, injecting organisation-specific guidance, compliance prompts, or links to documentation without editing the core client. - **Usage:** Extend the intro banner provider registry with plugin-discovered providers that can append new sections or rewrite existing ones. Plugins could surface mandatory security reminders, company hotkeys, or dynamic status indicators fetched from monitoring APIs while preserving the default capability overview for new operators. ## Persistent user chat transcripts - **Purpose:** Preserve the auxiliary terminal chat history across server restarts so operational directives sent from the supervising user remain auditable. - **Usage:** Extend the `UserChatBridge` with pluggable transcript writers that stream each emitted message into structured storage (for example, newline-delimited JSON). Provide rotation policies, remote sinks (such as syslog or HTTP POST targets), and tooling to replay transcripts into the MCP logging bus when a client reconnects mid-session. ## Interactive chat status mirroring - **Purpose:** Surface delivery acknowledgements, failure diagnostics, and plugin-generated notices inside the terminal helper process so operators receive immediate visual feedback without consulting logs. - **Usage:** Expand the inter-process control channel to forward server-generated status messages using the existing append envelope. Add bridge hooks that format status updates, append them to the console history, and optionally highlight warnings or errors with colour-coded text for rapid operator assessment. ## Console messaging hotkey profiles - **Purpose:** Allow deployments to customise the activation key, cancellation bindings, and prompt phrasing used by the console messaging bridge so that they align with internal runbooks or avoid clashing with terminal shortcuts. - **Usage:** Extend `ServerConfig` with a console messaging profile that defines the activation key, cancellation keys, and prompt text. The profile should be validated for cross-platform compatibility and exposed through the plugin registry so administrators can ship environment-specific presets. ## Operator message policy hooks - **Purpose:** Enable security and compliance teams to approve, redact, or transform operator-sent messages before they reach clients, ensuring that sensitive guidance does not leak unintentionally. - **Usage:** Introduce a plugin hook fired immediately before `_broadcast_message` transmits to sessions. The hook should receive the raw message, the formatted prefix, and contextual metadata such as the timestamp and connected session count. Plugins can veto delivery, substitute content, append audit annotations, or trigger out-of-band notifications when policy rules are violated. ## Operator messaging command-line companion - **Purpose:** Provide a non-interactive utility that can inject operator messages into the running server now that the standalone terminal window has been retired. - **Usage:** Implement a small CLI entry point (for example `mcp2term-send-message`) that connects to the existing chat bridge transport, authenticates using short-lived tokens, and submits structured messages. The tool should support templated payloads, dry-run validation, and integration with automation systems so supervisors can broadcast scripted status updates without requiring physical access to the server console. ## Console stream observability hooks - **Purpose:** Expose metrics and structured events from the new pause-aware console stream proxies so that monitoring systems can alert when output buffering persists or grows unexpectedly. - **Usage:** Introduce a registry of observers that receive callbacks whenever `ConsoleStreamProxy` transitions between paused and active states or flushes buffered output. Observers should record buffering duration, data volume, and caller metadata so operators can diagnose slow consumers or misbehaving plugins. Provide sample integrations for Prometheus and OpenTelemetry exporters. ## Warning delivery health monitoring - **Purpose:** Detect when client-side warning sinks repeatedly fail so operators can proactively repair integrations before users lose critical diagnostics. - **Usage:** Track notice-writer failures within `RemoteMcpSession`, exposing counters and backoff strategies through telemetry hooks. When repeated failures occur, escalate by surfacing a consolidated status banner to the interactive shell and emitting structured events to plugins so downstream observability pipelines can alert maintainers. ## File metadata diffing - **Purpose:** Allow operators to compare consecutive `stat` results so that automated workflows can detect drift in permissions, ownership, or size without scraping terminal logs. - **Usage:** Persist the most recent metadata snapshot for each inspected path inside the client state store, then extend the `filetool stat` command with an opt-in flag (for example `--diff-previous`) that renders side-by-side changes. The server should expose an efficient metadata checksum to avoid transmitting redundant fields, and plugins could subscribe to metadata change events to trigger alerting or remediation pipelines. ## Substitution preview mode - **Purpose:** Allow operators to verify `substitute` results without mutating files, providing confidence before large-scale replacements. - **Usage:** Introduce a `--dry-run` flag that reports match counts, diff excerpts, and regex group expansions while leaving the file untouched. The server would reuse the existing substitution engine but skip writes, returning detailed metadata for auditing tools and interactive confirmation prompts. ## Anchor-aware range edits - **Purpose:** Extend anchor-driven workflows beyond insertion so teams can replace or delete sections relative to literal or regex sentinels without manually calculating line numbers. - **Usage:** Build on the new anchor matching engine to allow `replace` and `delete` operations to target anchors, optionally spanning multiple matches, while preserving the existing line-based interface for compatibility. ## Configurable Python path exports - **Purpose:** Allow operators to append additional directories or opt out of the automatic launch-directory export when integrating with virtual environments or workspace managers that maintain their own module search paths. - **Usage:** Extend `ServerConfig` with an export policy structure that can add, remove, or prioritise directories before the launch directory is injected. Provide CLI switches and environment variables so deployments can describe the desired ordering while keeping the launch-directory guarantee available as the default behaviour. ## Progress notice customisation policies - **Purpose:** Allow operators and plugin authors to tailor the long-running command notice content, include structured metadata such as elapsed durations, and localise the phrasing for diverse deployment environments without patching the executor. - **Usage:** Introduce a configuration block and plugin hook that accepts a progress notice policy object. The policy should define the rendered message template, optional metadata attachments for MCP log consumers, and thresholds for when additional diagnostics (such as process tree snapshots) should be emitted. Provide documentation so administrators understand how to register policies and expose sample templates for common operations, including localisation examples. ## Spinner filtering policy hooks - **Purpose:** Allow deployments to customise which transient spinner characters are suppressed while console echoing is paused, ensuring real diagnostic punctuation is not inadvertently filtered. - **Usage:** Expose a configuration surface on `ConsoleStreamProxy` and matching server configuration to override the default spinner fragment set or disable filtering. Provide plugin hooks so environments that rely on bespoke progress indicators can register additional characters or entirely custom suppression logic at runtime. [Vorschlag] Introduce user-configurable newline management policies for streaming contexts so operators can decide when synthetic delimiters should be injected for long-running command notices and stdout mirrors. This builds on the new separator guarantees and lets deployments fine-tune how closely the mirrored output should follow the raw process streams. TODOS: [TODO] Extend `_ContextEmitter` with a lightweight policy object describing desired newline behaviour per stream. [TODO] Surface the policy through `ServerConfig` with environment variable overrides for quick tuning. [TODO] Document recommended configurations for TUI clients, web dashboards, and legacy terminals so operators can pick sensible defaults. [Vorschlag] Add structured progress notice payloads that include elapsed time, most recent output excerpt, and optional plugin-provided diagnostics so clients can display rich status tiles without parsing plain-text strings. This complements the separation changes by leveraging the dedicated notice channel. TODOS: [TODO] Define a dataclass describing the structured progress payload forwarded to MCP contexts and plugins. [TODO] Update `_monitor_long_running_command` to populate the payload with elapsed durations and most recent stdout timestamps. [TODO] Provide client-side adapters that render the structured payload while retaining backward compatibility with plain-text notices. [Vorschlag] Offer regression tests that simulate diverse stdout interleavings (mixed newline and no-newline chunks, PTY output, and stderr bursts) to guarantee the separator logic remains stable under future refactors. TODOS: [TODO] Build parametrised tests covering PTY and pipe-based executions with varied chunk boundaries. [TODO] Validate that plugin listeners and console echo streams receive unmodified data alongside the formatted context messages. [TODO] Integrate the new tests into CI pipelines with timing controls to minimise flakiness.