Problem
build_run_sim and launch_app_sim currently start OSLog capture with a fixed predicate:
subsystem == "<bundleId>"
That means simulator run flows no longer expose the older log-capture behavior that allowed callers to broaden or customize the subsystem filter (for example app-only vs SwiftUI vs custom subsystems vs all logs). This is a regression for users who need runtime logs outside the app bundle ID subsystem.
Current behavior
build_run_sim extracts the app bundle ID from the built app and passes it to launchSimulatorAppWithLogging.
launch_app_sim accepts a user-provided bundleId and passes it to launchSimulatorAppWithLogging.
launchSimulatorAppWithLogging validates bundleId, then startTrackedOsLogStream builds the fixed OSLog predicate using that bundle ID.
- There is no public tool argument for custom subsystem filters or broader OSLog capture.
Expected behavior
Expose a public, structured option for simulator OSLog filtering so callers can request useful non-default capture modes without raw predicate injection risk.
Suggested shape, matching the old intent:
subsystemFilter?: 'app' | 'all' | 'swiftui' | string[];
Semantics:
app: current default, subsystem == "<bundleId>"
all: omit --predicate
swiftui: include app subsystem and com.apple.SwiftUI
string[]: include app subsystem plus caller-provided subsystem names
Security requirement
PR #407 reintroduced validation for the current fixed predicate by validating bundleId before it is interpolated into:
--predicate subsystem == "<bundleId>"
If custom filter arguments are added, the same validation needs to be applied at the predicate-construction boundary:
- Validate
bundleId.
- Validate every caller-provided subsystem string.
- Allow only alphanumeric characters, dots, hyphens, and underscores.
- Reject invalid values before spawning any
simctl launch or log stream helper.
- Do not expose raw NSPredicate strings unless there is a separate security model for arbitrary predicate syntax.
Acceptance criteria
build_run_sim and launch_app_sim expose the same OSLog filter option.
- Invalid subsystem values return structured tool failures before spawning helpers.
- Structured output includes a diagnostic explaining the invalid filter value.
- Tests cover quotes/backslashes/predicate operators in both bundle ID and custom subsystem filter values.
- Default behavior remains unchanged: app subsystem only.
Problem
build_run_simandlaunch_app_simcurrently start OSLog capture with a fixed predicate:That means simulator run flows no longer expose the older log-capture behavior that allowed callers to broaden or customize the subsystem filter (for example app-only vs SwiftUI vs custom subsystems vs all logs). This is a regression for users who need runtime logs outside the app bundle ID subsystem.
Current behavior
build_run_simextracts the app bundle ID from the built app and passes it tolaunchSimulatorAppWithLogging.launch_app_simaccepts a user-providedbundleIdand passes it tolaunchSimulatorAppWithLogging.launchSimulatorAppWithLoggingvalidatesbundleId, thenstartTrackedOsLogStreambuilds the fixed OSLog predicate using that bundle ID.Expected behavior
Expose a public, structured option for simulator OSLog filtering so callers can request useful non-default capture modes without raw predicate injection risk.
Suggested shape, matching the old intent:
Semantics:
app: current default,subsystem == "<bundleId>"all: omit--predicateswiftui: include app subsystem andcom.apple.SwiftUIstring[]: include app subsystem plus caller-provided subsystem namesSecurity requirement
PR #407 reintroduced validation for the current fixed predicate by validating
bundleIdbefore it is interpolated into:If custom filter arguments are added, the same validation needs to be applied at the predicate-construction boundary:
bundleId.simctl launchorlog streamhelper.Acceptance criteria
build_run_simandlaunch_app_simexpose the same OSLog filter option.