Proposal: non-activating observations, inline screenshot reuse, private input comparison and early response evidence
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 20/100
- Issue type
- Feature
- Clarity
- Needs clarification
- Activity status
- Stale
- Tech stack
- android, ios, typescript
Research direction
Start with the agent-device snapshot -i --observe-only --json entry point and review implementation PR #3108, including its refusal, capability, runner-continuity, and live-simulator coverage. Treat the remaining checklist items as separate follow-ups; the issue is done only when each selected contract has applicable local gates and live evidence without changing the stated existing behavior.
Written by the indexing model from the issue text.
Description
Purpose
Propose small contributions from an existing fork: non-activating observations, inline screenshot reuse, private Android input comparison, and bounded early post-action response evidence. These complement existing upstream owners. Default foreground repair and its targetActivation disclosure remain unchanged.
First contribution: iOS snapshot without activation
The first PR is intentionally narrower than trustworthy foreground-owner verification:
agent-device snapshot -i --observe-only --json
Successful data.observation:
{
"mode": "observe-only",
"activationPerformed": false,
"appState": "runningForeground",
"appStateSource": "xcuiapplication-state"
}
The guarantee is no activation or foreground repair, not verified screen ownership. XCTest must report runningForeground before and after capture, and the process identity must remain unchanged. The capture does not substitute a system surface and never emits targetActivation.
Admission requires an explicit app session and an already-ready local iOS runner. A non-activating capability probe and the snapshot stay pinned to the same runner session. Unsupported capability, missing state provenance, changed process/session, or unavailable observation fails closed; this mode never starts/restarts a runner or falls back to an activating capture.
Native refusal is OBSERVATION_UNAVAILABLE, also retained in error.details.runnerErrorCode. Host/capability refusals use COMMAND_FAILED with details.reason: "observation-unavailable"; unsupported owners/platforms use UNSUPPORTED_OPERATION. Ordinary snapshot repair/disclosure is unchanged.
Why the narrower contract matters
#2682, #2691 and #2693 implement disclose; this adds opt-in prevent. It addresses the absence of positive no-activation evidence raised around #2694, but does not close #2694's ordinary coordinate/live-ref interaction disclosure gap.
#2696 records false XCUIApplication.state == runningForeground reports while another app is on screen. AX activeApplications/otherActiveApplicationPid establishes accessibility-session liveness, not foreground ownership. Neither is promoted into a certainty guarantee. Stronger ownership remains a separate research follow-up. Live verification also sees foreground state briefly persist after Home, reinforcing the need for explicitly sourced state rather than a screen-ownership assertion.
Follow-up use cases and safety
- Post-action observation policy: proposed
--settle-observe-onlyconstrains the settled captures, not the caller's explicitly requested mutation. Reuse the existing observation/readiness engine and preserve mutation admission/dispatch disclosure. - Early response history: retain bounded, privacy-projected captures already made during settle so brief toasts/validation responses survive. Include timestamps, truncation and provenance. Historical nodes grant no refs, coordinates, current-state authority or secret readback; the final ref-issuing frame stays separate.
- Inline screenshots: reuse existing inline PNG capture and non-activating display resolution rather than add a parallel stream protocol. Investigate the remaining CLI/transport memory-only path, bounded PNG validation, captured-app/process/session provenance and incompatible file/tracing options. Never log image-bearing payloads; a requested bundle ID alone is not pixel provenance.
- Private Android comparison: extend #2289 through the existing IME helper, receiving expectations through bounded private stdin/transport, never process arguments. Return
match,mismatchorunknown, not text or implicit length disclosure. Preserve nonce/target/focus/input-connection-generation binding, fresh complete extraction, authenticated transport and IME restore gates. Partial/stale/truncated/null/changed-focus reads remain unknown. - Prerelease helper version codes: separately fix the current mapping of prereleases to version code
1, deriving a bounded/range-checked code from the semver core without porting fork release metadata.
Existing coverage / remaining delta
- #2290 already preserves Android editable/password/hint/selection metadata: exclude that fork commit.
- #2925 fixes iOS software-keyboard focus reporting; Android already reports focus. Reuse both, not another focus field.
- #2926 improves Android fill-verification sampling; private comparison of masked values remains #2289.
- #2864 carries post-gesture outcomes; #3072 and #3081 own observation/readiness polling and waits. Remaining deltas are early content history and an opt-in observation policy, not another polling engine.
- #3071 owns failed-interaction dispatch disclosure; keep that distinct from post-action content evidence and do not change resend policy.
- #2728 and the existing inline PNG response already cover non-activating native screenshot capture. Reuse them.
- #1626 concerns observation cost, not a no-repair policy. Preserve existing system-surface handling and comparison lineage (#2450) outside observe-only.
Small PR checklist
- iOS
snapshot --observe-only: implementation submitted in #3108 (awaiting upstream review/CI), with the narrowed contract, preserved default disclosure, refusal/capability/runner-continuity regressions and live simulator evidence. - Extend policy to settled post-action captures without changing mutation admission or dispatch disclosure.
- Retain bounded privacy-projected early settle history while preserving the final ref frame.
- Reuse inline PNG capture for a guarded memory-only CLI/transport path; prove no files or image-bearing diagnostics are produced.
- Extend #2289's Android private comparison with same-length wrong-value and privacy/focus/generation/partial-read cases.
- Fix prerelease helper version codes separately.
- Research stronger foreground-owner evidence and fail-closed unsupported environments separately; do not infer ownership from AX PID ordering.
No downstream product naming or fork release metadata belongs in these contributions. Each implementation PR should include applicable local gates and live evidence before being called merge-ready.
- Dominant language
- TypeScript
- Stars
- 4.8k
- Forks
- 315
- Avg merge
- 11h 17m
- Merged PRs (30d)
- 536
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from callstack/agent-device
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
callstack/agent-device#1869 ·
Maintainers usually reply within 1 day
-
needs-triage refactor
Difficulty 5/5 Over a week Newbie friendliness 25/100
callstack/agent-device#3116 · 4 comments ·
Maintainers usually reply within 1 day
-
Difficulty 3/5 1-2 days Newbie friendliness 68/100
callstack/agent-device#3105 ·
Maintainers usually reply within 1 day
-
Difficulty 3/5 1-2 days Newbie friendliness 72/100
callstack/agent-device#3104 ·
Maintainers usually reply within 1 day
-
needs-triage
Difficulty 4/5 3-5 days Newbie friendliness 38/100
callstack/agent-device#3077 ·
Maintainers usually reply within 1 day
All issues in callstack/agent-device
Similar issues
-
bug HemiStake
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
hemilabs/ui-monorepo#2413 ·
Maintainers usually reply within 1 day
-
component/ui framework/react kind/bug language/javascript
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
meshery/meshery#22216 · 3 comments ·
Maintainers usually reply within 1 day
-
type/bug
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
paperclipai/paperclip#14982 ·
Maintainers usually reply within 1 day
-
community first-timers-only good first issue hacktoberfest help wanted low hanging fruit up-for-grabs
Difficulty 1/5 Under an hour Newbie friendliness 95/100
lingdojo/kana-dojo#31515 · 1 comment · 5 reactions ·
Maintainers usually reply within 1 day