BootUI properties

BootUI reads its bootui.* configuration from the host application's own configuration — Spring Boot property sources on the Spring adapter, MicroProfile Config on the Quarkus adapter. It is local-only by default: it activates only in development contexts, rejects non-loopback callers, masks secret-like values, and disables itself for production profiles unless explicitly forced on.

Panel settings are consistent across the UI and API:

• Every visible panel has bootui.panels.<panel-id>.enabled with default true.
• Panels with browser-triggered actions also have bootui.panels.<panel-id>.read-only with default false.
• bootui.read-only=true makes every action-capable panel read-only, even when the per-panel read-only flag is false.
• Disabled panels are moved to the Disabled / unavailable sidebar group and their registered panel API routes return 403. Scorecard and Command Line have no panel API prefix: their panel switches hide the navigation entry, not /overview or the CLI transport; bootui.cli.enabled controls the latter.
• Read-only panels keep read endpoints visible but block mutating API requests. Safe methods (GET, HEAD, OPTIONS) remain allowed.

Spring vs Quarkus (cross-adapter parity)

BootUI targets Spring Boot and Quarkus from one codebase, and its bootui.* keys are largely the same by name on both adapters — but they are read by different configuration engines, and a few keys are platform-specific.

How keys are read. On Spring, most static bootui.* settings are bound into a @ConfigurationProperties object; early activation and agent claims read the prepared environment. Spring's relaxed binding applies (camelCase, kebab-case, and underscores are all accepted). On Quarkus, keys are read through MicroProfile Config and must be written in exact kebab-case. Safety policy is read live, per request; a missing or invalid value fails closed (for example, masking stays on and non-loopback access stays denied). Most keys below are honored identically on both adapters. Static bounds such as the PostgreSQL row limits require an application restart on every adapter.

The MySQL properties follow the same JDBC-backed cross-adapter configuration contract and static-limit restart requirements.

Activation. Spring decides activation at runtime from bootui.enabled and the enabled-profiles / disabled-profiles lists (plus DevTools). Quarkus decides activation at build time from the launch mode: the console is wired in dev and test and is completely absent (prod-dark) in a production build. The three Spring activation keys therefore have no effect on Quarkus.

Host application namespace. The host application itself is configured with its own framework's properties — spring.* on Spring, quarkus.* on Quarkus. BootUI does not read spring.* keys on Quarkus; its advisors bridge the two namespaces internally (for example, the Hibernate advisor maps the Spring property names its rules expect onto their quarkus.hibernate-orm.* equivalents).

Keys that are not shared

Keys with a shared name but platform-specific behavior

The remaining shared settings use the same names and defaults wherever their backing capability exists; a property does not add a missing integration. These include the safety keys (bootui.allow-non-localhost, bootui.allowed-hosts, bootui.trusted-proxies, bootui.trust-container-gateway, bootui.authentication.token), bootui.expose-values, bootui.mask-secrets, bootui.path / bootui.api-path, bootui.monitoring.exclude-self, bootui.http-exchanges.max-exchanges (default 200), bootui.http-exchanges.reserved-share-percent (default 25), bootui.activity.request-slow-threshold-ms (default 1000), bootui.log-tail.max-bytes (default 0, meaning unbounded), and the bootui.github.*, bootui.vulnerabilities.* (including osv-base-uri, default https://api.osv.dev), bootui.sql-trace.*, bootui.runtime-journal.*, bootui.postgresql.*, bootui.mysql.*, bootui.runtime-insights.*, bootui.code-inventory.*, bootui.resources.*, bootui.telemetry.* (except max-request-bytes), bootui.heap-dump.*, bootui.exceptions.*, bootui.security-logs.*, bootui.cache.* (except .activity-capture-enabled and .activity-max-events, Spring only — see above), bootui.mcp.*, bootui.cli.*, bootui.ai.*, bootui.copilot.*, and bootui.claude-code.* families. It also includes the per-panel access keys — bootui.panels.<id>.enabled / .read-only and the global bootui.read-only — which are enforced on Quarkus by QuarkusPanelAccessFilter at full behavioral parity with Spring's PanelAccessFilter (same config keys, same BootUiPanels path resolution, same canonical JSON 403 body); see "Panel access settings" below.

Global settings

Remote API authentication

The configured static SPA remains available after non-loopback access is explicitly enabled, but the configured API surface requires authentication for a caller whose raw TCP peer is neither loopback, nor within a configured bootui.trusted-proxies range, nor a gateway trusted by bootui.trust-container-gateway. bootui.allow-non-localhost=true bypasses only source rejection, never this authentication requirement. Paste the startup token into the unlock screen; BootUI exchanges it for an HTTP-only, SameSite=Strict session cookie scoped to the browser-visible API path (including the host application's context/root path), which also authenticates SSE streams and downloads. CLI, MCP, and OTLP clients should send the token using the standard HTTP bearer authorization scheme.

Localhost, configured trusted proxy, and trusted gateway requests remain frictionless and do not require a token. Trusting a proxy or gateway therefore changes both source acceptance and authentication; Host and cross-site-write protection still apply. Bind container ports to loopback and keep trust ranges narrow. Authentication is an additional layer: activation, source trust, Host validation, cross-site-write protection, panel access, and read-only checks still apply. Use HTTPS for direct remote access because bearer credentials sent over plain HTTP can be intercepted.

Custom UI and API paths

bootui.path is configurable on Spring MVC, Spring WebFlux, and Quarkus. /bootui remains the exact backward-compatible default. When only the UI path is set, the API path is derived after normalization:

bootui.path=/dev-console/
# Effective API path: /dev-console/api

Use bootui.api-path only when the API must live elsewhere:

bootui.path=/dev-console
bootui.api-path=/internal/bootui-api

Both values are relative to the application root. server.servlet.context-path, spring.webflux.base-path, or quarkus.http.root-path is prepended automatically and exactly once. Do not include that framework root in the bootui.* values.

BootUI trims surrounding whitespace and trailing slashes. It rejects blank or root paths, . / .. path segments, duplicate interior slashes, query/fragment content, percent encoding, backslashes, routing metacharacters, and any character outside RFC 3986's unreserved path-segment set. Invalid active configuration fails startup with the property name in the error. The UI path also cannot be nested below /bootui/**, which is reserved for Quarkus' private internal classpath mount; the exact /bootui default is valid, and the API default /bootui/api remains valid.

With a custom UI path, the old packaged /bootui mount is answered with 404 rather than retained as a compatibility alias. The generated SPA shell receives the fully composed UI/API locations at runtime, so assets, API calls, SSE, downloads, MCP configuration, and OTLP setup copy all follow the configured paths.

Panel access settings

Enforced identically on Spring and Quarkus (PanelAccessFilter / QuarkusPanelAccessFilter).

Per-panel action details

Advisor violation retention

Shared by Architecture, Hibernate, Spring/Quarkus application, REST API, Memory, Security, and Database Advisor on their supported stacks. The limit is captured when a scan starts, including across Hibernate persistence units; zero, negative, and invalid values are not an unlimited mode. Only the latest snapshot is retained. Counts and existing ten-/twenty-entry summary samples remain unchanged when retention is exhausted; report violationDetails.truncated and each detail page's truncated explicitly disclose missing entries.

Raising this setting requires a new explicit scan to retain previously omitted details; it cannot fill an existing snapshot. Detail pages default to 100 entries, at most 1000, and MCP/CLI also enforce their transport budgets. Reads remain available with bootui.read-only=true or a panel's read-only setting; disabled/unavailable panels remain gated. Retrieval completeness does not affect evidence coverage or scores. See reading every retained violation.

Startup Timeline

HTTP Sessions

GitHub

Configuration

Loggers

REST API

Spring

Spring Security

Security Logs

Security

Pentesting

Cache

Hibernate

Hibernate Statistics

Enable for this runtime starts statistics collection for the current application process only. It does not rewrite application configuration or reset existing counters, and it does not require confirmation. The action is blocked when either bootui.read-only=true or bootui.panels.hibernate-statistics.read-only=true. To enable collection persistently from startup, set spring.jpa.properties.hibernate.generate_statistics=true on Spring or quarkus.hibernate-orm.statistics=true on Quarkus, as recommended by HIB-CONFIG-007.

Database

Run Database checks performs bounded, read-only JDBC schema introspection. It does not require confirmation and is blocked when either bootui.read-only=true or bootui.panels.database-advisor.read-only=true.

PostgreSQL

These properties apply to Spring MVC, Spring WebFlux, and Quarkus. Each row limit applies independently to each datasource and is shared by reads from the browser, REST API, MCP, and CLI.

Row limits are static: restart the application after changing them, including when saved through Spring's Configuration panel. Values must be integers from 1 to 2147483646, inclusive. Zero, negative values, invalid integers, and 2147483647 are rejected rather than clamped or treated as unlimited. The upper endpoint leaves room for the one extra row used to detect truncation; it is not a recommended operating limit.

For example, to retain a deeper statement ranking and inspect more relations:

bootui.postgresql.max-statements=250
bootui.postgresql.max-tables=500
bootui.postgresql.max-vacuum-tables=500

The existing safety bounds stay fixed: a 5-second statement timeout, a 2-second lock timeout, a 15-second overall read budget, and a 400-character statement-text limit. Raising row limits can increase read cost and does not guarantee a complete result before these deadlines. Row-limit omissions retain PARTIAL / truncated=true and name the affected sections; timeouts and permission failures remain distinct explanations. In the UI, a statement-ranking cap alone is an informational note inside that section, not a page-wide warning. Other capped sections and actual read problems still produce visible warnings. See PostgreSQL for read behavior and availability.

MySQL

These defaults apply to Spring MVC, Spring WebFlux with JDBC, and Quarkus with JDBC. They do not add R2DBC or reactive-client-only support. Browser, REST, MCP, and CLI reads share the same limits.

The seven row limits are static: restart the application after changing them, including changes saved through Spring's Configuration panel. Every value must be an integer from 1 to 2147483646, inclusive. Invalid, non-positive, and overflowing values fail startup with a property-specific error; zero is not unlimited. The upper endpoint reserves one extra row for truncation detection, not a recommended operating size.

Current timing/text bounds are 15 seconds for the cooperative whole read, 5 seconds per server-bounded SELECT, 2 seconds for metadata-lock waiting, and 400 displayed statement characters. The inspection connection's JDBC network guard is at most 7 seconds, retaining a tighter existing positive timeout; it covers control/SHOW I/O and is restored after collection. The SHOW GLOBAL STATUS fallback uses 17 fixed safe names, not the SELECT execution-time guarantee or max-settings. These are not extra configuration properties or hard end-to-end deadlines. Pool acquisition can exceed the cooperative budget; application connection/socket configuration remains separate. Increasing row caps changes neither these bounds nor the settings/InnoDB allow-lists. Row omissions set truncated; timeouts, denied sources, and disabled instrumentation remain distinct limitations. See MySQL for permissions, evidence scopes, and safety.

Memory

Flyway

Liquibase

SQL Trace

Transactions

REST Client

WebSockets

BootUI never reads, decodes, or stores a WebSocket message payload on any stack; only frame size, direction, type, and destination are recorded, and provider session ids are replaced by a short one-way hash before they leave the process.

AI Framework

Live Activity

The Live Activity panel reuses the HTTP Exchanges, SQL Trace, REST Client, Exceptions, Security Logs, Cache, Scheduled Tasks, and Email sources, so disabling any of those panels through their own bootui.panels.* toggles also removes them from the stream. Kafka, RabbitMQ, and JMS capture additionally have their own bootui.kafka.*, bootui.rabbitmq.*, and bootui.jms.* toggles—see below—and each stops feeding Live Activity when its dedicated panel is disabled. Reading the feed changes nothing. Its Clear recording and Free BootUI memory actions are blocked by bootui.read-only or bootui.panels.activity.read-only. A request whose correlated SQL trips bootui.activity.n-plus-one-threshold is flagged with a red N+1 badge both in the main stream row and in its profile drawer (the same threshold, so the two views never disagree); the drawer additionally lists the flagged group's call site(s) whenever bootui.sql-trace.capture-call-site is enabled.

Live Activity Kafka capture

When Kafka support is present, BootUI captures producer/consumer outcomes into the Live Activity stream as MESSAGING entries. Spring does this by wrapping application-owned KafkaTemplate and @KafkaListener container factory beans; Quarkus does it through SmallRye Reactive Messaging Kafka interceptors. Only metadata is captured — topic, partition, offset, a hash of the key, timing, success/failure, consumer group id when exposed, and listener id — the message value/payload is never captured, and failure text is generic so exception messages cannot leak payload or credentials. On Spring, the consumer group is available and the listener-id field currently carries the listener container factory bean name (not the resolved per-@KafkaListener id); on Quarkus the group is unavailable and the channel name is used as the listener id. Quarkus outgoing capture requires OutgoingKafkaRecordMetadata to be attached before the interceptor; payload-only emissions that rely solely on channel configuration are not recorded. See Live Activity specification.

Live Activity JMS capture

On Spring MVC and WebFlux, spring-jms activates metadata-only capture for application-owned JmsTemplate and @JmsListener container factories. JMS has its own bounded recorder and settings, independent from Kafka and RabbitMQ, so one transport's traffic cannot evict another transport's history. Destination names are control-character-stripped, length-bounded, and credential-like URI/user-info or password/secret/token/API-key assignments are masked before storage. Unknown provider-specific Destination implementations are not rendered because their toString() output can expose broker metadata. Raw message IDs, payloads, arbitrary headers/properties, and exception messages are never stored; when a MessageCreator or MessagePostProcessor exposes the provider-assigned message ID, only its SHA-256 hash is retained. Quarkus does not claim a JMS capture integration.

Live Activity RabbitMQ capture

When RabbitMQ support is present, BootUI captures publish/consume activity as MESSAGING entries. Spring composes with application-owned RabbitTemplate before-publish processors and listener-factory advice; Quarkus uses SmallRye Reactive Messaging RabbitMQ interceptors. Message bodies and arbitrary headers are never captured. Routing metadata is bounded, correlation IDs are omitted by default and stored only as a SHA-256 hash when explicitly enabled, and failure details are generic so exception messages cannot leak payload or credential data. On Quarkus, producer exchange, consumer queue, and producer duration are unavailable because SmallRye's callbacks do not expose them; outgoing capture also requires OutgoingRabbitMQMetadata to be attached before the interceptor.

Live Activity durable persistence

Off by default: the merged stream stays in-memory-only, exactly as above. Setting bootui.activity.persistence.enabled=true additionally buffers captured entries and flushes them to a SQL database over direct JDBC, so history survives a restart and the dashboard can page back further than fits in memory. Available on both adapters with an identical config surface and wire contract; on Quarkus a QuarkusActivityCapture CDI bean (@Observes StartupEvent/ShutdownEvent) owns the journal capture's lifecycle instead of Spring's controller-inline wiring. Durable history is written by the runtime journal's subscriber, whatever source the feed reads; with the journal disabled, persistence logs a warning and writes nothing. See the Live Activity specification for the full design (the ActivityStore abstraction, buffering/flush, merge-for-reads, re-queue-on-failure, the flush guard, and multi-tenancy).

Runtime journal

BootUI 2.0's runtime journal records every runtime event once, in a bounded in-memory structure, and keeps running aggregates per route, statement, exception group, transactional method, and thread family. Recording never blocks a request: events wait in a bounded queue for one BootUI daemon thread, and an event the queue cannot take is dropped and counted. HTTP requests, SQL statements, exception occurrences, security events, REST client calls, cache accesses, messages, scheduled runs, transactions (Spring), logical database connections (how long each was waited for and held), application WARN and ERROR log events, outgoing emails (their recipient and attachment counts only), fault-tolerance outcomes, AI operations (ai: operation, provider, model, tokens, and finish reason, never prompts or answers, from Spring AI's model observation or Quarkus LangChain4j's chat listener, stamped with their request, and otherwise from recognized GenAI spans linked to their request by trace id), garbage collections (gc), authorization decisions (authorization: what was checked, the rule when Spring Security names it, whether the caller was anonymous or authenticated, whether access was granted, and a count of authorities, from Spring Security's authorization observations or Quarkus's authorization events), and the run's start (lifecycle: the time to ready and the slowest bean instantiations on Spring, and the facts that decide whether two runs can be compared: active profiles, each data source's URL shape such as jdbc:postgresql://localhost without credentials, database, or parameters, the cache in use, whether tracing is on, and the recorded sources; then markers for BootUI's own successful actions, naming the panel, method, and path without query or body, availability changes once the application is ready, Spring Cloud configuration refreshes with the changed key names, and shutdown), and application events (app-event: each event type published and each listener's run, with its transaction phase and whether it ran, was deferred, failed, or was skipped for lack of a transaction, never the event's fields; framework events are left out), and WebSocket messages (websocket: each inbound application message a handler ran, as an execution of its own, with its endpoint, its destination as the mapping's template such as /app/chat/{room}, its size when known, and whether its handler failed, never its content, headers, or session), and Hibernate sessions (orm: per session, its statements and their time, connection acquisitions, full flushes and the auto-flushes that wrote before a query, with Hibernate's own flush time, the most entities its persistence context held at a flush, and second-level cache hits, misses, and puts, never an entity, a parameter, or a statement) are recorded. On Spring, BootUI names its session listener in spring.jpa.properties.hibernate.session.events.auto; on Quarkus, in each persistence unit's unsupported-properties."hibernate.session.events.auto", such as quarkus.hibernate-orm.unsupported-properties."hibernate.session.events.auto" for the default unit, in dev and test mode only, which Quarkus reports at startup as an unsupported property. Either way, an application's own listener wins and the source then records nothing. The resources source measures each request's CPU time, allocated bytes, and the collections that completed while it ran, summed over the measured threads its work ran on. The JVM does not measure virtual threads, so a request served on one reports its CPU time and allocated bytes as unavailable or partial, never as zero. Payloads hold no bind values, keys, message bodies, exception or log messages, or principals: a log event keeps its unformatted template only. Apart from opt-in durable activity persistence, the journal writes nothing to disk unless bootui.runtime-journal.baseline-file is set, and that file holds a run summary only: route templates, statement fingerprints, call sites, exception-group ids, thread families, observed edges, counts, histograms, and, with the BootUI agent, the run's side-effect keys (hosts and ports, masked file patterns, process file names, and variable names), never principals, literals, SQL text, values, arguments, or file contents. The same keys and defaults apply on Spring and Quarkus. The journal's recorded SQL, log text, and request paths in Live Activity, and the log text and request paths Runtime Insights quotes, follow bootui.expose-values and bootui.mask-secrets at each read; Runtime Insights always quotes a statement's literal-free shape.

The journal is enabled by default. One Spring MVC sample-route benchmark measured 14.1 % lower median throughput with it on than off, missing the 5 % target; this single workload is not a general application estimate. The maintainer's decision is to keep the default on (validation report).

Recording a source is not enough to see it: each source belongs to the panel that publishes it, and disabling that panel leaves its events out of Live Activity, request profiles, Runtime Insights, and the MCP tools and CLI commands over them, with the panel named as the reason. http belongs to HTTP Exchanges, sql and connection to SQL Trace, transaction to Transactions, exception to Exceptions, security and authorization to Security Logs, rest-client to REST Client Trace, cache to Cache, messaging to its broker's panel (Kafka, RabbitMQ, or JMS, so disabling one broker leaves the others), scheduled to Scheduled Tasks, log to Log Tail, mail to Email, fault-tolerance to Fault Tolerance, ai to AI, websocket to WebSockets, orm to Hibernate, agent.executors to Java Agent, and agent.caught-exceptions to Exceptions. lifecycle, gc, resources, and app-event belong to no panel: they are not panel-gated, but still require the journal and their entry in bootui.runtime-journal.sources to be enabled.

Resource correlation

While the runtime journal records the resources source, one BootUI daemon thread sweeps the JVM once per interval. Its CPU ledger splits the process's CPU time three ways: the share credited to requests, the rest of each thread family's share (BootUI's own threads as one family), and the JVM's own work (GC, JIT, VM threads, and threads the sweep did not read), which together sum to the process's CPU time. Its resource track keeps heap use, heap after collections, allocation, and thread counts. The 900 most recent points are kept in memory, outside the journal's byte bound.

Traces

HTTP Exchanges

HTTP Probe

Email

Kafka

The Kafka panel is a dedicated, filterable view over the same producer/consumer capture that feeds Live Activity's MESSAGING entries — see "Live Activity Kafka capture" above for the shared bootui.kafka.* capture properties (enabled, capture-key, max-entries, max-key-length), which tune both surfaces identically.

RabbitMQ

The RabbitMQ panel is a dedicated view over the same bounded capture that feeds Live Activity. On Spring it is available when a RabbitTemplate bean exists; on Quarkus it is available when quarkus-messaging-rabbitmq is present in dev/test mode. The bootui.rabbitmq.* properties above tune both surfaces.

Fault Tolerance

The Fault Tolerance panel reads protective policies live from Resilience4j registries, Spring Retry @Retryable metadata, and SmallRye Fault Tolerance annotations captured at build time on Quarkus. It is strictly capture-only: BootUI never opens, closes, resets, or otherwise mutates a circuit breaker, retry, rate limiter, bulkhead or time limiter. Captured events are metadata only — policy name, outcome, attempt number, duration, exception simple name, and circuit breaker state — never method arguments, return values or exception messages.

JMS

The JMS panel is a dedicated view over the same bounded Spring JMS capture that feeds Live Activity. The bootui.jms.* properties above tune both surfaces. Quarkus reports this panel not yet available.

Exceptions

Log Tail

Vulnerabilities

Heap Dump

Threads

Architecture

GraalVM

CRaC

Java agent

The Java Agent panel shows the agent's status and offers the bounded runtime sensor switches. On Spring, bootui.agent.* is read at startup, before the application context exists, so a configuration change applies at the next start or DevTools restart; the sensor switches are in-memory overrides until the JVM exits. On Quarkus these keys are build-time properties, read when the application is built (augmented); dev mode rebuilds when they change, while runtime sensor overrides last until the JVM exits.

The main application package on Spring and the application archive packages on Quarkus are always included. bootui.agent.packages only adds extra prefixes.

How much of a method probe's argument and return shapes BootUI shows follows bootui.expose-values and bootui.mask-secrets, and the memory the agent's evidence may use outside the journal is bounded by bootui.runtime-journal.agent-evidence-max-bytes.

Code Inventory

The Code Inventory panel is view-only and needs the BootUI agent's inventory sensor. Once per run, off the request path, BootUI scans the application's own class files in the claimed packages and hashes their methods; these keys bound that scan. On Spring they are read when the context starts, on Quarkus at runtime.

Code Paths

The Code Paths panel needs the BootUI agent's code-paths sensor (bootui.agent.sensors) and has no property of its own: its route trees are bounded in code, at 2,000 nodes a route, 100,000 nodes and 500 routes a run, and its method probes at 20 invocations, 60 seconds, and five probes at once; a smaller agent-evidence byte bound shrinks tree limits. Method probes are its only actions: bootui.panels.code-paths.read-only=true, or the global bootui.read-only=true, refuses starting and stopping them, in the browser/API, and starting through MCP/CLI. Stopping has no MCP tool or CLI command. Disabling it with bootui.panels.code-paths.enabled=false also stops route-time-breakdown from splitting the handler by method.

Side Effects

The Side Effects panel is view-only, needs the BootUI agent's side-effect bridge and its sensors (processes, network, files, blocking, and resources by default, environment, thread-activity, thread-locals, and security-sinks opt-in, in bootui.agent.sensors), and has no property of its own. bootui.panels.side-effects.enabled=false hides the panel and rejects its reads. Runtime switches shown inside this panel are actions of the Java Agent panel, so bootui.panels.java-agent.enabled and .read-only, plus global read-only policy, govern them.

In this version every sensor in the panel ships: processes, network, files, blocking, resources, and the opt-in environment, thread-activity, thread-locals, and security-sinks record. resources tracks sockets through network and file streams through files, both on by default; security-sinks also needs bootui.agent.security-sinks.request-values=true to hold the request values it matches. blocking is not-applicable on Spring MVC until a WebClient's event loop is registered. A network target is a host string and port, never resolved, without user information, with characters other than letters, digits, and . _ - : [ ] / ~ as ?, at most 128 characters, and at most 1,024 distinct ones a run; a looked-up name is the host name alone. A file row shows a path pattern (./ for the working directory, $TMPDIR, ~, ids and digits collapsed), never contents; an environment row shows a name, never a value. The process target is the sanitized command name only: for a process that started, the file name of its executable after the last path separator; for a failed start, the first command element up to whitespace or =, then after the last path separator; an element that opens with a quote, as Windows starts "C:\Tools\app.exe" --token x, keeps only its quoted text, and nothing past a quote inside an element is kept. Only letters, digits, ., _, +, and - are kept; other characters become ?, and the result is at most 128 characters. Arguments and environment variables are never recorded. While HTTP Exchanges is disabled, route-attributed rows merge under (route hidden: HTTP Exchanges is disabled) and do not expose request ids. While Code Paths is disabled, rows lose their inside bean method and merge without it. Clear recording and Free BootUI memory clear Side Effects rows through the agent evidence contract, and journal status counts sideEffectRows and sideEffectsWaiting under Agent evidence.

Spring DevTools

Dev Services

Copilot

Claude Code

MCP server

The MCP server exposes BootUI's advisors and read-only diagnostics to local AI agents (GitHub Copilot, Claude Code) over a loopback-only Model Context Protocol endpoint at POST <bootui.api-path>/mcp (default POST /bootui/api/mcp). It is off by default and only ever active while BootUI itself is active: absent from a Quarkus production build, and disabled by the Spring prod and production profiles unless an explicit bootui.enabled=ON overrides them. Tools inherit the same safety model as the panels: read tools require the backing panel to be enabled, action (*_scan) tools are additionally refused when the panel is read-only, and all values flow through the same secret masking as the REST API.

Before dispatching a request that needs a response, BootUI measures the response-too-large fallback with the original correlation id in the selected protocol era. If it cannot fit, the transport refuses with HTTP 413 and an empty body, before invoking a tool, acquiring a concurrency slot, or opening a stream. It never truncates or coerces the id, substitutes null for a valid id, or raises the configured limit. This is BootUI's resource admission policy, not a protocol-mandated HTTP status. Validation and parse errors are also byte-bounded, without changing which error is selected first; legitimate notifications still answer bodyless 202. Every budget refusal increments responseLimitRefusals once.

Spring JSON replies and all SSE payloads use compact JSON; Quarkus JSON replies use its application's Jackson configuration. Admission covers both possible representations when a client accepts SSE, because a call can still answer with JSON. The budget counts the rendered JSON only, not HTTP headers, the SSE data: prefix, blank lines, or heartbeat comments.

Command-line endpoint

The command-line endpoint projects the same tool registry the MCP server exposes onto plain REST, so a terminal or a CI job can ask a running application one diagnostic question without an MCP client. GET <bootui.api-path>/cli (default GET /bootui/api/cli) describes the tools this instance advertises, and POST <bootui.api-path>/cli/tools/{name} invokes one, returning its payload directly with the outcome in the HTTP status (403 panel disabled or read-only, 404 unknown tool, 400 bad argument, 409 action already running, 429 at capacity, 504 timeout).

It is on by default, because it is a different spelling of data the panel endpoints already serve rather than a new capability: every tool remains gated by its panel's enable/read-only settings, and the endpoint sits under bootui.api-path, so the loopback, Host allow-list, cross-site-write, and bootui.authentication.token protections apply unchanged. It does not require bootui.mcp.enabled, and its calls are counted separately so the MCP Server panel keeps reporting only what agents did.

Make the whole application read-only:

bootui.read-only=true

Hide one panel entirely:

bootui.panels.devtools.enabled=false

Keep one panel visible but disable its actions:

bootui.panels.config.read-only=true

Require both an action gate and panel read-only state to allow an action:

bootui.panels.dev-services.read-only=false
bootui.dev-services.restart-enabled=true