Repository navigation
iOS parameterized input remains in native XCTest diagnostic logs #3261
Description
Activity
Additional bounded simulator control: we entered the inert digits
284690using the stock coordinate-keyboard route with action recording disabled, then performedis exists 'label="Settings"' --no-recordand a deliberately invalid-ref press with--no-record. No post-entry snapshot command was issued in this control. The same digits appeared in the native.xcresultdiagnostic log.This means avoiding
fill/typeTextand using--no-recorddid not prevent native value persistence during this entry-and-completion-check sequence. We have not isolated which of the subsequent operations produces each native log line; we are not claiming every coordinate tap independently logs the complete value.Confirmed on a physical iPhone as well, using the unmodified official 0.21.22 runner with automatic signing and a separate fresh task-owned state/session. The Settings Search control used another inert marker,
INERT_STOCK_PHONE_CANARY_20261006, with the samefill({text, recordAs})→ stable predicate → invalid-ref error sequence.The inspected JSON/session outputs were redacted, but that exact marker appeared in the physical runner's
.xcresultnative diagnostic log. This extends the observed scope beyond Simulator. No real credential or masked-password field was tested.Downstream scope update: our owner has clarified that these dedicated QA fixtures may appear in local test-device diagnostics. We are proceeding with the official unmodified release for that test-account workflow; this report is not a request to block ordinary automation or to maintain a downstream patch. The inert reproduction above remains valid, and documentation or supported handling of this native-log boundary would still be useful for callers whose inputs require stronger protection.
Decision: document the boundary now; prevention is separate research. Your simulator and physical-device controls show that XCTest's own diagnostic logs and the xcresult can contain typed text, and nothing in this repo controls them today.
keepNeverand coordinate entry don't change that.Next steps:
- Docs: state that the privacy guarantee for typed input covers agent-device's own output, logs and artifacts, and does not cover XCTest's native diagnostic logs or the xcresult on iOS.
- Research, keeping this issue open: whether the runner can stop XCTest from recording the parameter, or remove or redact the xcresult it owns, without breaking runner diagnostics.
Moving secrets off argv is tracked in #3260.
- addeddocumentationImprovements or additions to documentationImprovements or additions to documentation
on Oct 9, 2026
Observed behavior
On unmodified
agent-device@0.21.22, a harmless value supplied through the Node API withfill({ text, recordAs })was correctly absent from the fill response, subsequent predicate/error responses, and the inspected Agent Device session artifacts, but remained verbatim in the native XCTest.xcresultdiagnostic log.We are trying to use the official release for iOS login automation without carrying a downstream patch. Is there a supported way to prevent sensitive visible input from being retained by this native diagnostic channel? If this is outside the parameterization guarantee, documenting that boundary would also help.
Environment
202585240f0c1289642885b5df645cbc25114272recordAs; no screen recording, trace, or app-log capture requestedReproduction outline
Boot an owned iOS simulator and open Settings with the stock CLI in a fresh state directory/session:
agent-device open com.apple.Preferences --platform ios --udid "$SIM_UDID" \ --session stock-canary --save-script --foreground --timeout 120000 --jsonUse the official Node client for that same session. Take a fresh snapshot and select the unique Settings
SearchFieldwith labelSearch. Then execute:Inspect the exact runner's
.xcresultStaging/1_Test/Diagnostics/.../Session-AgentDeviceRunnerUITests-*.logfor the inert marker. Our observed excerpt:A second run using another inert marker and
fill({ ..., verify: false })also retained its marker in the native diagnostic log. The stock XCTest plan already sets system/user attachment lifetime tokeepNever; that did not prevent this diagnostic text.This establishes persistence during the sequence, not that the deliberately failed press alone caused it. We have not yet established the behavior on a physical iPhone or a masked password field. The visible Settings input was a control for a visible OTP field.
Expected / requested guidance
A documented stock path for sensitive visible input that avoids retaining its literal value in native diagnostics, or an explicit documented limitation so callers can stop before supplying credentials. We are not asking to disable ordinary observations globally.
Related: #1348 and #1398 provide useful recording/response redaction, and those protections worked in the checks above. #3260 separately concerns CLI input transport; it would not by itself address native diagnostics.