BootUI feature details

BootUI panels are documented here in the same grouped order as the application menu. When a panel's backing infrastructure is missing, the sidebar moves non-overview panels into the collapsed Disabled / unavailable group so you can tell at a glance which panels have no live data for the current application. Opening a dimmed panel also shows the unavailable reason at the top of the page.

Every visible panel can be hidden with bootui.panels.<panel-id>.enabled=false. Panels with browser-triggered actions also support bootui.panels.<panel-id>.read-only=true, and bootui.read-only=true makes the whole BootUI application read-only. The complete list is in the property reference.

Monitoring-oriented panels hide BootUI's own runtime data by default so Beans, Conditions, Mappings, Loggers, Metrics, Startup Timeline, Scheduled Tasks, Spring Cache, Spring Security, Security Logs, and Traces stay focused on the host application. Set bootui.monitoring.exclude-self=false to include BootUI internals while debugging the console itself.

Overview

The Overview panel is the BootUI landing page and acts as a guided "understand your app in minutes" dashboard rather than a static summary. It opens with a hero banner and quick links to the running application's homepage and the BootUI GitHub project, followed by two live cards: a Health card that polls the Actuator health status and a Memory card that renders the current JVM memory breakdown (heap, metaspace, code cache, direct memory, and thread stacks). Both cards auto-refresh while the tab is visible.

Below the live cards is an on-demand security & health scoring dashboard. An overall score out of 100 summarizes the application's posture, with a qualitative band (Good at 80+, Needs attention at 50+, At risk below 50) and a breakdown of how much each scanner deducted from a perfect score. A single "Run all scanners" button triggers every available scanner, or each scanner card can be run individually.

Each scanner card shows its own 0–100 score, status, and severity counts. The severity-based scanners are Architecture, Hibernate Advisor, Security Advisor, Vulnerabilities, and Pentesting; scores start at 100 and subtract a fixed weighted penalty per finding (critical 25, high 10, medium 3, low 1), so a clean scan stays at 100. The GitHub card is not a severity scanner: it connects to the local repository and, only when the credential is connected and authenticated, contributes a score derived from open security alerts. The overall score is the mean of the scanners that were actually scored, and only scanners whose panels are available for the current application are shown, so the dashboard degrades gracefully when optional infrastructure is missing.

GitHub

The GitHub panel sits directly under Overview and summarizes the current project's GitHub state from the local origin remote. It uses BootUI's standard auto-refresh control with a one-minute interval while the tab is visible; the initial refresh and each interval are bounded and blocked by the panel's read-only settings.

The panel shows repository metadata and an eight-card summary grid with click-through detail drawers for open pull requests, open issues, the latest GitHub Actions executions, quotas, Copilot usage report availability, and the three security signals. The open-issues drawer summarizes the label/staleness buckets and then lists the bounded set of open issues returned by the refresh, linking each to its issue page with its author, labels, comment count, and last-updated time (pull requests returned by the issues endpoint are excluded). GitHub Actions execution rows link to the matching run, show the workflow, branch, event, status, and duration, and mirror the recent-run list from the GitHub Actions page. The workflow failure count only considers the latest execution for each workflow and branch, so older failures drop out once a later run fixes that workflow on that branch; security signal drawers link to the matching GitHub alert pages. The quota card shows the lowest remaining quota percentage with a red-to-green threshold palette. The quota drawer is hidden by default, renders every resource returned by GitHub's /rate_limit response dynamically, highlights resources with 10% or less remaining or at quota, then adds best-effort cards for repository or owner quotas such as Actions cache, artifacts, and Actions billing when the credential can access those endpoints. Copilot usage uses GitHub's organization report metadata endpoint when available; BootUI shows the report window and link count only, without downloading or exposing signed report URLs.

Credentials are read from the current device only: GITHUB_TOKEN, GH_TOKEN, or an existing gh auth token login. The token is never sent to the browser, persisted by BootUI, or included in warnings; without a token, public repositories use GitHub's unauthenticated rate limits. Refreshes are bounded by per-request timeouts, a maximum API-call budget, and a quota safety threshold that skips optional sections before exhausting the core API quota.

Runtime

Health

The Health panel displays the Actuator health tree, including nested contributors and detailed status information when the host app exposes it. It keeps unavailable health data separate from unhealthy application state so missing Actuator infrastructure is clear, and shows setup guidance instead of a healthy-looking status when the Actuator health endpoint is not available. When Actuator health is present but only Spring Boot's default indicators are reported, it keeps the live statuses visible and shows guidance for adding application or dependency health contributors.

HTTP Sessions

The HTTP Sessions panel lists local embedded Tomcat sessions with creation time, last access time, idle duration, attribute count, and current-session highlighting. Session identifiers are treated as bearer credentials: by default the UI only receives an opaque action key and a masked display id, and every attribute value is masked. Setting bootui.expose-values=FULL reveals display ids and stringified attribute values for local troubleshooting and shows an explicit FULL exposure warning, while METADATA_ONLY keeps attribute names and types without values. The panel returns at most 50 sessions by default; raise bootui.http-sessions.max-sessions if a local app needs a larger bounded view.

Clear and destroy actions are confirmation-gated and disabled by global or per-panel read-only mode. Clear removes all attributes from the selected session while keeping it valid; destroy invalidates the selected session. When the app is not running on embedded Tomcat, the panel shows an unavailable state instead of guessing at container internals.

Metrics

The Metrics panel browses Micrometer meters exposed by Actuator. You can inspect meter descriptions, base units, tags, available measurements, and render a local live chart for a selected metric/tag combination.

Memory

The Memory panel summarizes current live JVM heap and non-heap usage plus memory pool utilization. It stays focused on the running process metrics so you can spot high heap pressure, non-heap growth, and pool-level saturation without the JVM sizing controls mixed into the view.

Tuning Advisor

The Tuning Advisor panel uses the same live JVM context to review current JVM input arguments, explain spring.threads.virtual.enabled=true, and run JVM sizing calculators for both dedicated hosts and Kubernetes. It detects whether Spring virtual threads are enabled in the current application, shows an information or warning bubble, and feeds that detected state into platform-thread stack budgets and heap sizing recommendations without adding the Spring property to generated JVM or Kubernetes snippets.

The bare-metal calculator partitions a target JVM process memory budget into heap, metaspace, code cache, direct memory, thread stacks, and headroom, then turns that plan into copyable JVM options with fixed -Xms and -Xmx values. The Kubernetes calculator keeps requests.memory == limits.memory for Guaranteed QoS by default, but can switch to a snapshot-based Burstable request when the operator intentionally overcommits memory. Its JAVA_TOOL_OPTIONS uses -XX:MaxRAMPercentage and -XX:InitialRAMPercentage instead of fixed heap sizes so the JVM heap follows the container memory limit when an operator resizes the pod. A Spring Boot Actuator probes toggle initializes from the current health probe configuration and, when enabled, adds startup/readiness/liveness probe YAML plus the health-probes property. Fixed non-heap caps remain visible in the snippet and sizing notes because they still need to fit inside any smaller limit.

Heap Dump

The Heap Dump panel captures local JVM heap dumps on demand and analyzes them through a value-free class histogram, so you can investigate suspected memory leaks or unexpected retention during the local development loop. Capture and analyze actions run an explicit, confirmed request that triggers a full GC and writes an .hprof file under the configured output directory; the panel then shows live heap usage, the top retaining classes by instance count and shallow size, and the list of captured dumps with retention-based eviction.

Heap dumps can contain plaintext secrets, credentials, and personal data, so the panel is designed to be safe by default: it only summarizes class names and sizes (never object values), all capture/analyze/delete operations are mutating POST requests that are blocked when the panel is read-only, and downloading the raw .hprof file is disabled unless explicitly enabled via configuration. Use it on a local JVM only, and treat any exported dump as sensitive.

Threads

The Threads panel shows a live snapshot of the JVM's threads so you can answer "what is the application doing right now?" during local development. It reads thread information in-process through ThreadMXBean rather than requiring the host application to expose the Actuator threaddump endpoint, and presents a state summary header (counts per thread state), a flag when a deadlock is detected, and virtual-thread context when running on a JDK that supports it. The thread list supports server-side filtering by name and by state with paging, and each row can expand to show its stack trace.

Stack frames and thread names can incidentally contain sensitive values, so the panel reuses BootUI's masking and value-exposure model: names are masked when they look like secrets, and stack traces are omitted entirely under metadata-only exposure. The raw text thread dump is offered as a confirmation-gated POST download that is blocked when the panel is read-only. The panel stays loopback-only and fails closed, showing an explained unavailable state instead of disappearing when thread information cannot be read.

Startup Timeline

The Startup Timeline panel visualizes Spring Boot startup steps from Actuator startup data. It helps identify expensive startup phases, slow bean initialization, and the overall application startup shape. When BootUI is active, the starter installs a BufferingApplicationStartup by default so the panel has data without host-app setup; disable that with bootui.startup.enabled=false or tune the retained step count with bootui.startup.capacity. If startup data is still unavailable, the panel shows an empty state instead of failing.

GraalVM

The GraalVM panel surveys the host application for GraalVM native-image readiness. On demand it imports the application's own classes (bounded to the detected base package(s)) and runs a curated set of heuristic checks for constructs that native-image cannot resolve at build time — reflection, dynamic class loading, deep reflection, dynamic proxies, runtime resource loading, resource bundles, service loading, serialization, build-time-initialization side effects, and native access. With the Include dependencies toggle on (the default), it also surveys the classpath to report which third-party libraries already ship reachability metadata under META-INF/native-image/. From the same scan the panel generates a downloadable reachability-metadata.json scaffold (modern unified schema, with condition.typeReached guards) seeded with reflection/serialization candidates and the standard configuration resource globs. The checks and generated metadata are heuristic review aids that complement, but do not replace, the GraalVM tracing agent and an actual native build. See GRAALVM-READINESS-CHECKS.md for the full catalogue of checks and what each one inspects.

Configuration

Configuration

The Configuration panel shows effective configuration properties, sources, metadata descriptions, defaults when known, active profiles, and masked values. It can create, update, and delete local runtime overrides persisted to .bootui/application-bootui.properties, with restart and rebinding caveats shown for every mutation. Large property tables load in bounded server-side pages for search, source, and override-only filters. The override property-name picker limits its datalist suggestions while narrowing against the full metadata catalog as you type.

Profile Diff

The Profile Diff panel compares profile-specific property sources and values. It is useful for understanding what changes between local development profiles while still routing browser-visible names and values through BootUI's secret masking rules.

Loggers

The Loggers panel lists runtime logger configuration from Actuator. It shows configured and effective levels, supports server-side search, and can update or clear logger levels without restarting the application. Large logger lists load in bounded pages while filtering still searches the full logger set.

Beans

The Beans panel helps answer which Spring beans exist and where they came from. It supports server-side search across bean names and types, plus classifications such as application, Spring framework, Java/Jakarta, and other beans. BootUI's own beans are hidden by default; when self-data filtering is disabled they are classified separately as BootUI beans. Large bean lists load in bounded pages so the initial payload stays small while filters still apply to the full bean set.

Conditions

The Conditions panel explains Spring Boot auto-configuration decisions. It groups positive matches, negative matches, and unconditional classes so you can see why an auto-configuration applied or why it was skipped. Large condition reports load in bounded pages, and filtering runs on the server so the browser does not need the full report before narrowing results.

Mappings

The Mappings panel lists HTTP routes from Actuator mappings data. It shows request methods, path patterns, handlers, and produces/consumes metadata so the running application's web surface is visible without reading controllers manually. Large mapping lists load through a stable, paged BootUI DTO, and the filter continues to search every discovered route on the server.

Database

Database Connection Pools

The Database Connection Pools panel inspects supported JDBC connection pool beans. It is read-only and fails closed when no supported pool implementation or pool beans are present. For each pool it shows the pool identity, masked JDBC URL and username, driver, min/max sizing, and timeout/lifetime settings, and surfaces a clear unavailable reason for closed or uninitialized pools. A local live chart polls bounded snapshots of active, idle, total, and pending connections every two seconds so you can watch saturation trends without leaving BootUI. It never executes SQL, borrows connections, or resizes pools.

Spring Data

The Spring Data panel inspects Spring Data repositories. It shows repository interfaces, domain types, ID types, and query methods, and degrades to a clear empty state when Spring Data is not present or no repositories are registered.

Hibernate Advisor

The Hibernate Advisor panel runs an explicit, read-only scan against the JPA EntityManagerFactory metamodel when Hibernate ORM is present. It reviews mapped entities, selected persistence configuration, and Spring Data repository metadata for common Hibernate/JPA performance and mapping risks such as eager fetching, problematic identifier generators, collection fetch pagination, unsafe cascades, cache misconfiguration, and risky ddl-auto values. The report is framed as a review prompt, not a verdict: it never intercepts queries, invokes repositories, executes SQL, or modifies mappings. See HIBERNATE-CHECKS.md for the full rule catalogue and remediation links.

Flyway

The Flyway panel shows schema migrations for each Flyway bean in the context and lists, per database, the current schema version together with applied and pending migrations (version, description, type, script, state, installed-by, installed-on, execution time, and checksum). Multiple or named datasources appear independently. When Spring Modulith module-aware Flyway migrations are active, the panel shows the root and module-specific history tables separately so module-local migrations are visible even though Spring Modulith creates those Flyway views only during migration.

The panel also exposes confirmation-gated migrate and clean actions. They are available by default for trusted local sessions and are blocked by bootui.read-only=true or bootui.panels.flyway.read-only=true; clean also requires Flyway's own clean-disabled=false setting. Spring Modulith module-aware entries are read-only in BootUI because their module-specific history tables are managed by Spring Modulith's migration strategy. The panel degrades to a clear empty state when Flyway is not on the classpath or no Flyway beans are present.

Liquibase

The Liquibase panel shows change sets for each SpringLiquibase bean in the context. It reads the change-log history and configured changelog, then lists applied and pending change sets per database (id, author, change-log, description, comments, execution type, date executed, order executed, checksum, tag, deployment id, contexts, and labels). Multiple or named datasources appear independently.

The panel also exposes a confirmation-gated update action that applies pending change sets. It is available by default for trusted local sessions and is blocked by bootui.read-only=true or bootui.panels.liquibase.read-only=true. The panel fails closed per bean when its history cannot be read and degrades to a clear empty state when Liquibase is not on the classpath or no SpringLiquibase beans are present.

Security

Spring Security

The Spring Security panel inspects Spring Security filter chains and provides best-effort endpoint rule explanations. It is meant to explain local security wiring without exposing credentials or replacing a full security audit.

Security Logs

The Security Logs panel reads recent Spring Boot audit events from the application's AuditEventRepository, including authentication successes/failures and authorization denials when Spring Security audit listeners are active. When BootUI is active and the panel is enabled, it contributes an in-memory repository if the host app has not already defined one, which also lets Spring Boot create its standard audit listeners. It supports filtering by principal, event type, and time window, summarizes retained event counts by type, uses the shared visibility-aware auto-refresh controls, and masks sensitive event data before rendering. Responses are bounded by bootui.security-logs.max-logs, which defaults to 500; if audit support is explicitly disabled with management.auditevents.enabled=false, the panel remains unavailable.

Security Advisor

The Security Advisor panel runs an explicit, read-only scan of the host application's registered Spring Security SecurityFilterChain beans and related security beans when Spring Security is on the classpath. It introspects the filter lists, simulates an anonymous authorization decision, and inspects security-relevant beans (PasswordEncoder, CorsConfigurationSource, JwtDecoder) and Environment properties to flag common hardening gaps across authentication, authorization, CSRF, session management, transport/security headers, CORS, method security, actuator exposure, OAuth2 resource-server validation, and configuration hygiene. The report is framed as a review prompt, not a verdict: it never intercepts live traffic, exposes credentials, keys, or session identifiers, or modifies the security configuration. See SECURITY-ADVISOR-CHECKS.md for the full rule catalogue and remediation links.

Pentesting

The Pentesting panel runs explicit, local-only OWASP Top 10 2025 hygiene checks against the host application, not BootUI's /bootui routes. It combines passive Spring metadata with bounded synthetic localhost requests under the application context path for missing or unsafe security headers, CORS behavior, cookie flags, verbose error exposure, Spring Security wiring, and actuator exposure. It also inspects Spring Boot configuration for common hardening gaps such as wildcard actuator exposure, health detail exposure, an enabled H2 console, in-config security credentials, value-revealing actuator endpoints, request-detail logging, and DevTools left on the classpath. It intentionally does not sweep discovered application endpoints, send SQL/XSS/destructive payloads, or store raw response bodies. Findings are heuristic review prompts, not proof of exploitability or a replacement for a full security assessment.

Each hygiene check is registered with a stable identifier, OWASP 2025 category, evidence source, and recommendation so new checks can be added without expanding the scanner's HTTP surface. See PENTEST-CHECKS.md for the full catalogue of checks and what each one inspects.

Vulnerabilities

The Vulnerabilities panel shows dependency inventory and local OSV vulnerability scan results. It helps identify known vulnerable dependencies from the running project's dependency set during the local development loop. Scan findings are ordered by severity first, with dependencies and advisories alphabetized within the same severity.

Services

Scheduled Tasks

The Scheduled Tasks panel lists scheduled jobs registered with Spring scheduling infrastructure. It shows task type and trigger metadata so background activity is visible during local development.

Spring Cache

The Spring Cache panel inspects Spring Cache infrastructure. It lists cache manager beans, known caches, native implementations, safe local sizes, Micrometer cache metrics when registered, and discovered @Cacheable, @CachePut, and @CacheEvict operations. Cache clear actions are enabled by default for local development, require explicit browser confirmation, and can be disabled with bootui.cache.clear-enabled=false.

AI Usage

The AI Usage panel summarizes Spring AI and LangChain4j activity collected from OpenTelemetry spans emitted by their built-in observability. It groups chat client and chat model spans by conversation so you can see request count, token usage ( prompt, completion, total), latency, model, and the prompt/response snippet when the framework is configured to capture content (for Spring AI: spring.ai.chat.client.observations.log-prompt, spring.ai.chat.observations.log-prompt, spring.ai.chat.observations.log-completion; for LangChain4j: enable GenAI message-content capture on the OpenTelemetry instrumentation). A small inline chart shows total token usage over recent calls so you can spot expensive interactions during local development. Vector store and embedding spans appear alongside chat spans when present. The BootUI starter captures local application spans automatically when telemetry is enabled. Cooperating local services can still send OTLP spans to the embedded receiver. The sidebar dims the panel when telemetry is disabled or neither Spring AI nor LangChain4j is on the classpath, and the view explains the unavailable state. When no framework is detected, the setup checklist also shows two side-by-side guides — one for Spring AI and one for LangChain4j — explaining the dependency and configuration each needs to emit GenAI spans (including optional prompt/completion content capture). When both prerequisites are ready but no chat spans have arrived yet, the panel shows a ready empty state rather than setup guidance. Recent chats, model breakdowns, token-series windows, spans, and attributes are bounded so large local runs stay responsive. As with the Traces panel, data is sourced from BootUI's local telemetry capture, is in-memory only, and is cleared on restart.

Diagnostics

Traces

The Traces panel shows distributed tracing spans captured locally by the BootUI starter when telemetry and the Traces panel are enabled. The starter contributes the tracing dependencies and sampling default needed for local development, so the host application does not need manual management.* tracing properties. BootUI also keeps an embedded OTLP/HTTP receiver at /bootui/api/otlp/v1/traces so cooperating local services can export spans into the same in-memory store. The list shows the most recent traces with service name, root span name, status, duration, and span count; opening a trace renders a waterfall view of its spans so you can see latency contributions, errors, and parent/child relationships across services. Spans emitted by BootUI's own API are filtered out on ingestion by default, and retained self-only traces are hidden from the panel, to keep the view focused on application traffic. Span ingestion can be tuned with bootui.telemetry.exclude-self-spans=false; read-time panel filtering follows bootui.monitoring.exclude-self. When bootui.telemetry.enabled=false, the sidebar dims the panel and the view shows a disabled state instead of implying that tracing is merely empty. The in-memory trace buffer is bounded by bootui.telemetry.max-traces, bootui.telemetry.max-spans-per-trace, request-size limits, and attribute-value truncation, with additional internal caps to keep misconfigured local exporters from overflowing the UI. Trace data is reset on application restart or via the panel's clear action.

Log Tail

The Log Tail panel reads recent local application logs and streams new log events from the running process. It is intended for quick local diagnosis without leaving the BootUI console.

HTTP Exchanges

The HTTP Exchanges panel records recent inbound requests handled by the running application. It lists timestamp, method, path, status, duration, response size when a Content-Length header is present, and trace identifiers from common propagation headers. Expanding a row shows request and response headers, with secret-like headers and query parameters masked unless bootui.expose-values=FULL is explicitly configured. BootUI self-requests are hidden from the panel by default through bootui.monitoring.exclude-self, though they still count against the bounded in-memory recorder.

BootUI contributes an in-memory HttpExchangeRepository when the panel is enabled and no application repository already exists. The default buffer retains 200 exchanges and can be changed with bootui.http-exchanges.max-exchanges; changing that capacity requires an application restart. If the repository is unavailable, the panel shows a clear unavailable state instead of implying that no traffic has occurred.

HTTP Probe

The HTTP Probe panel sends local-only requests to the running application and displays response status, headers, duration, and body. It is designed for quick route checks from inside the same local development context as BootUI.

Architecture

The Architecture panel runs a curated, zero-config ArchUnit ruleset against the host application's own classes at runtime. It detects the application's base package from the @SpringBootApplication configuration, imports the compiled classes from that package, and evaluates a fixed set of universally-sensible architecture hygiene rules: package cycles between slices, general coding practices (no standard streams, generic exceptions, java.util.logging, JodaTime, printStackTrace, System.exit, JDK-internal APIs, legacy date/time, or deprecated APIs, poorly named exceptions/interfaces, mutable/visible loggers, production dependencies on test frameworks, public mutable static fields, or non-final utility classes), and Spring stereotype/proxy heuristics (no field injection, controllers should not depend on repositories, repositories should not depend on controllers or services, services should not depend on controllers, services and repositories should stay servlet-agnostic, no self-invocation or unproxyable proxy annotations, async/scheduled method signatures should be supported, async should stay out of configuration classes, stereotypes should stay outside the default package, @ConfigurationProperties classes should be immutable, stereotype dependencies should flow web → service → repository, and code should avoid AopContext.currentProxy()). When BootUI is installed through bootui-spring-boot-starter, ArchUnit is included transitively; the panel is available when a base package is resolvable and the scan runs on demand, caching the last report.

Generic rules are necessarily less powerful than project-authored ArchUnit tests, so the panel is positioned as a starting-point and review aid that complements — rather than replaces — a project-specific ArchUnit test suite. Each rule is registered with a stable identifier, category, severity, and recommendation; the rule results list shows only violating rules, sorted by severity and violation count. See ARCHITECTURE-CHECKS.md for the full catalogue of rules and what each one inspects.

Developer tools

DevTools

The DevTools panel reports Spring Boot DevTools availability, LiveReload status, and restart support. Restart actions are shown only when available and require explicit confirmation before execution.

Dev Services

The Dev Services panel surfaces local development services discovered from Docker Compose snapshots, Testcontainers beans, and service connection metadata. It masks sensitive connection information, can show bounded logs for supported services, and shows restart controls only for supported Testcontainers services when bootui.dev-services.restart-enabled=true. To keep opening the panel side-effect free, BootUI skips lazy, prototype, or otherwise uninitialized service beans that would need to be created just for inspection and reports those skips as warnings in the panel.

Masking scope: BootUI masks discovered connection details (for example credentials embedded in a JDBC URL or connection properties) before they reach the browser. Raw container log output is streamed verbatim, bounded by bootui.dev-services.log-tail-bytes, and is not scanned for secrets — a service that prints credentials to its own logs will surface them in this panel. This is consistent with BootUI being a local-only, loopback-restricted developer console.

Copilot

The Copilot panel surfaces sanitized signals from local GitHub Copilot CLI sessions. It reads the session directories and events.jsonl files Copilot CLI writes under ~/.copilot/session-state/ (configurable via bootui.copilot.session-state-dir) and aggregates recent activity into a clean dashboard: active sessions, total sanitized events, input/output token usage when the local session logs include it, failures, 24-hour activity, 7-day activity, event category mix, top tools, model usage, and recent sessions. The session explorer remains available for drilling into tool calls, edits, reads, searches, shell commands, web/docs lookups, MCP tool calls, hook callbacks, skills, sub-agents, and ASK/intent/plan calls. To keep large local histories responsive, the session explorer returns the most recent bootui.copilot.max-sessions sessions by default, while bootui.copilot.max-parsed-sessions caps how many recent session files are parsed and retained in JVM heap. The activity charts default to token usage, with input tokens shown in blue and output tokens shown in red, and can be toggled back to sanitized events/failures. Selecting a chart hour or day filters the explorer to sessions active during that window. Failure lists use retained failure events and include sanitized tool/type context. Each event row shows only an allowlisted summary - raw prompts, tool arguments, command output, and diffs are deliberately excluded. The per-event "Reveal raw" action is an explicit, local-only escape hatch that returns the source JSON; it can be disabled with bootui.copilot.allow-raw-reveal=false and is also blocked when bootui.expose-values=METADATA_ONLY. The sidebar dims the panel when no session-state directory is found. Data is read-only - BootUI never modifies anything under ~/.copilot/. The panel uses the same header refresh button and visibility-aware auto-refresh toggle as the other live data panels, while the backend watches the directory through a Java NIO WatchService thread. Inspired by copilot-mission-control, which pioneered this dashboarding of Copilot CLI session state.

Claude Code

The Claude Code panel mirrors the Copilot dashboard for local Claude Code project logs. It reads JSONL session files under ~/.claude/projects/ (configurable via bootui.claude-code.session-state-dir) and surfaces sanitized activity trends, tool usage, model usage, input/output token usage, failures, recent sessions, and per-session event drill-downs. Its activity charts use the same token-by-default view as the Copilot panel, with an events toggle for sanitized activity and failures. BootUI treats Claude Code logs as especially sensitive: prompts, assistant text, tool inputs, file contents, command output, and tool-result content are excluded from normal responses. bootui.claude-code.max-parsed-sessions caps how many recent JSONL files are parsed and retained in JVM heap. The raw JSONL reveal endpoint is disabled by default with bootui.claude-code.allow-raw-reveal=false; enabling it is an explicit local-only escape hatch and is still blocked when bootui.expose-values=METADATA_ONLY. The sidebar dims the panel when no Claude Code projects directory is found. Data is read-only - BootUI never modifies anything under ~/.claude/. Because Claude Code writes sessions inside per-project subdirectories, BootUI refreshes this panel through the shared visibility-aware auto-refresh polling used by the other live data panels.