Dashboard: Safari standalone web app (iOS home-screen web app) does not AutoFill or save the admin token

Client or integration

OpenCodex dashboard

Area

Dashboard

Summary

On iOS, the dashboard admin-token sign-in is never offered password AutoFill when the dashboard is installed as a standalone web app (Safari → Share → Add to Home Screen). Safari in the regular browser tab does offer AutoFill/Save for the same dialog; only the standalone home-screen web app does not. The admin token is long and random, so without AutoFill the only option is manual copy/paste on every sign-in.

The dialog already follows the standard shape (gui/src/admin-token-dialog.ts): a real <form method="post" action="..."> with a type="text" autocomplete="username" field and a type="password" name="password" autocomplete="current-password" field, plus a submit button. Submission is a normal submit event handler that calls preventDefault() and verifies the token via fetch. Despite that, the iOS standalone (WKWebView home-screen) context never shows the QuickType password suggestion bar for the field and never offers to save the credential, while the same page in Safari proper does.

Expected: the admin token field offers iOS password AutoFill (QuickType key / saved credentials) in the standalone web app, and Safari offers to save the credential after a successful sign-in.

Reproduction

Serve the dashboard on a LAN/Tailscale URL (ocx start).
In iOS Safari, open the dashboard and sign in with the admin token — AutoFill suggestions and the save-password prompt appear in the browser.
In iOS Safari, use Share → Add to Home Screen, then launch the dashboard from the home-screen web app.
Focus the admin token field: no password AutoFill suggestion bar appears, and after a successful sign-in Safari never offers to save the credential.

Version

2.48.0

Operating system

Server: Windows 11; client: iPhone, iOS (Safari standalone web app via Add to Home Screen)

Logs or error output

None — no server-side error; sign-in succeeds when the token is entered manually. The problem is purely that iOS standalone-mode Safari does not treat the field as a login credential field.

Screenshots and supporting files

Screenshot of the standalone web app sign-in showing the token field without any AutoFill suggestion bar (attached to the thread; can be re-attached on request).

Redacted configuration

Not provider/config specific — affects the dashboard sign-in dialog itself.

Checks

I searched existing issues and documentation.
I removed secrets, tokens, account details, request credentials, and personal data.

리뷰 · 우선순위 48 / 80

설명

이 이슈는 OpenCodex 대시보드를 iOS Safari에서 공유 → 홈 화면에 추가로 연 뒤(스탠드얼론 웹앱 / WKWebView 홈스크린 모드) 관리자 토큰 로그인 칸에 비밀번호 AutoFill(QuickType)과 저장 제안이 안 뜨는 문제입니다. 같은 URL을 일반 Safari 탭에서 열면 AutoFill·저장이 되고, 홈스크린 앱에서만 안 됩니다. 서버 쪽 401/검증 실패가 아니라, 긴 랜덤 admin token을 매번 손으로 붙여 넣어야 하는 UX 구멍입니다.

지금 dev HEAD(627274b8f, package 2.56.0) 기준으로 보면, 로그인 UI는 이미 비밀번호 관리자를 의식해서 짜여 있습니다. gui/src/admin-token-dialog.ts의 promptForAdminToken은 실제 <form method="post">에 autocomplete="username" 읽기 전용 계정칸(값은 고정 문자열 OpenCodex)과 type="password" name="password" autocomplete="current-password" 토큰칸, submit 버튼을 만듭니다. 주석에도 브라우저/비밀번호 관리자가 저장·자동완성을 제안할 수 있게 진짜 로그인 폼 모양을 쓴다고 적혀 있고, OpenCodex 쪽은 제출된 토큰을 메모리에만 두고 영속화는 브라우저에 맡깁니다.

제출 경로는 일반 폼 네비게이션이 아닙니다. submit에서 preventDefault()한 뒤 verifyToken(실제로는 gui/src/api.ts의 verifyAdminToken → /api/settings에 토큰을 실어 검증)으로 fetch합니다. 수락되면 resolveTokenAfter401이 state.session.token에 넣고 이후 API에 X-OpenCodex-API-Key로 붙입니다. 즉 “페이지가 POST로 넘어가서 서버가 Set-Cookie 하는 고전 로그인”이 아니라 SPA 다이얼로그 + AJAX 검증입니다. Safari 탭에서는 이 모양만으로도 AutoFill이 되는 경우가 많지만, iOS 홈스크린(디스플레이 모드가 사실상 스탠드얼론)에서는 Password AutoFill 휴리스틱이 훨씬 빡세고, AJAX 성공 뒤에 저장 제안이 안 나오는 일이 흔합니다.

셸도 스탠드얼론을 따로 선언하지 않습니다. gui/index.html에는 viewport·테마 스크립트만 있고 apple-mobile-web-app-capable / mobile-web-app-capable 메타도, manifest.webmanifest(display: standalone)도 없습니다. 사용자가 Safari에서 홈 화면에 추가하면 iOS가 북마크형 스탠드얼론으로 띄우는데, 그때 비밀번호 금고의 origin·표시 모드 판정이 탭 Safari와 갈라질 수 있습니다. 또한 폼이 <dialog> + showModal() 안에 있습니다. 모달 다이얼로그 안의 password 필드가 iOS AutoFill 후보에서 빠지는 사례가 플랫폼 쪽에서 보고된 적이 있어, “폼 마크업은 표준인데도 스탠드얼론만 실패” 증상과 잘 맞습니다.

범위는 #4055(원격 바인드에서 WebUI 세션을 오래 유지하거나 토큰 재입력을 줄이는 기능)과 겹치지만 같지 않습니다. #4055는 서버/세션 수명·비토큰 로그인 쪽 설계이고, 이 이슈는 “이미 있는 비밀번호 관리자 AutoFill이 홈스크린 앱에서만 안 먹는다”는 클라이언트/플랫폼 구멍입니다. 지금 dev의 메인 트랙(#4546 라우팅·probe lease #4626 등)과도 직교합니다. 보안 구멍이라기보다 iPhone으로 LAN/Tailscale 대시보드를 쓰는 운영자의 반복 입력 비용 문제입니다. 재현 OS는 리포터 기준 iOS + 서버 Windows 11, 대시보드 버전은 2.48.0으로 적혀 있으나 해당 다이얼로그 뼈대는 현재 dev에도 그대로 있어 회귀로 사라진 기능은 아닙니다.

gui/src/admin-token-dialog.ts:135-150 - submit에서 preventDefault 후 fetch 검증만 하고, 성공 시 navigator.credentials.store / PasswordCredential 저장 호출이 없음. iOS 스탠드얼론에서는 AJAX 로그인 뒤 저장 제안이 안 뜨는 대표 원인 후보.
gui/src/admin-token-dialog.ts:28-37 / 176-178 - 폼이 네이티브 dialog.showModal() 모달 안에 마운트됨. iOS Password AutoFill이 모달·오버레이 필드를 로그인 폼으로 못 볼 수 있음.
gui/src/admin-token-dialog.ts:51-58 - username이 고정값 OpenCodex + readOnly. 탭에서는 통하더라도, 스탠드얼론·비표준 포트(LAN/Tailscale) origin과 묶일 때 금고 매칭이 약해질 수 있음.
gui/index.html - apple-mobile-web-app / web app manifest(display:standalone) 선언이 없음. 홈스크린 추가 시 탭 Safari와 다른 AutoFill 정책이 적용될 여지가 문서화·대응되어 있지 않음.
gui/src/api.ts:286-289 - 프롬프트 수락 토큰은 메모리 session에만 유지. 브라우저 금고에 안 남으면 홈스크린 앱을 다시 열 때마다 긴 토큰을 다시 붙여 넣어야 함(리포터 고통의 직접 원인).

메인테이너의 판단이 필요한 지점

iOS 스탠드얼론 AutoFill을 “지원 목표”로 둘지, 문서에 한계로 적고 Safari 탭/비밀번호 앱 복붙을 공식 우회로로 둘지.
수정 축을 (a) 다이얼로그를 모달 밖 일반 페이지/비dialog 폼으로 바꾸기, (b) Credential Management API로 명시 store, (c) #4055식 서버 세션 쿠키·수명으로 AutoFill 의존을 줄이기 중 어디에 둘지.
Tailscale/LAN hostname·비표준 포트 origin에서 비밀번호 금고 항목이 탭과 홈스크린 앱 사이에 공유된다고 보장할 수 있는지(플랫폼 한계면 코드만으로 100% 해결 불가).
#4055와 한 PR로 묶을지, 이 이슈는 “폼/다이얼로그/Credentials API” 좁은 버그로 분리할지.

너의 추천

이슈는 열고, help wanted + 짧은 needs-investigation 코멘트로 두는 쪽을 추천합니다. 즉시 merge-train에 태울 핵심 버그는 아닙니다(우선순위 48). 다음 실험 순서는 (1) 같은 빌드에서 폼을 <dialog> 밖 일반 overlay/div로 옮겨 AutoFill이 돌아오는지 확인, (2) 수락 직후 navigator.credentials?.store로 PasswordCredential 저장 시도(지원 브라우저만), (3) 그래도 스탠드얼론만 실패하면 index에 PWA 메타/manifest를 최소로 넣고 재현, (4) 플랫폼 한계로 판명되면 가이드에 “홈스크린 앱 AutoFill 미보장 → Safari 탭 또는 #4055 세션 유지”를 명시. types.ts/config.ts 분할과는 무관하고 중복 이슈로 닫을 대상도 아닙니다(#4055는 인접·비중복).

이 댓글은 grok-bot이 작성했습니다

Correction on the original report: Safari proper (regular tab) does recognize the password field and does offer save/AutoFill — that part was never broken. The issue is specific to standalone mode (adding the page to the home screen and launching it as a web app): WebKit does not render password AutoFill or save prompts in standalone mode because that UI belongs to the browser chrome, which is absent.

This is a platform limitation, not something the dashboard can fix by changing the form.

A workaround has been implemented in #4649: an opt-in "Remember on this device" checkbox on the sign-in dialog stores the accepted token in localStorage, so the standalone web app signs in silently on subsequent launches. The token is verified server-side before use, and is cleared if rejected or if the checkbox is unchecked.

feat(dashboard): opt-in remember admin token on this device for stand…

Tracking: draft PR #4649 (opt-in remember-admin-token for standalone sign-in) is the current attempt at this.

Still present on dev: the AJAX dialog at gui/src/admin-token-dialog.ts:135-168 is what Safari's standalone web app will not treat as a credential form.

feat(dashboard): opt-in remember admin token on this device for stand…

Triage: priority: P3 — Safari standalone autofill for admin token.

Criteria (P3): Low: new provider/client integration, large or experimental feature (>2000 LOC or >50 files), RFC/roadmap, or long-stale branch.

Matched pull requests:

feat(dashboard): opt-in remember admin token on this device for standalone sign-in #4649 (would resolve this issue) — feat(dashboard): opt-in remember admin token on this device for standalone sign-in [priority: P3]

Closing: this Safari standalone AutoFill gap is tracked by the open opt-in remember-token PR #4649. Reopen if that route is declined.

Reopening: I closed this by mistake. It stays open while #4649 is under review.

Status from release train 4: the proposed fix, #4649 (opt-in "remember on this device"), was reviewed and is not being merged in this train. It stores the admin token in localStorage, which requires an explicit security review. It also still lacks a Forget action that works after logout, updated docs, and evidence from a real iOS home-screen launch; details are in #4649 (comment). This issue stays open because the Safari standalone sign-in problem is still real on dev.

Navigation Menu

Repository navigation

Dashboard: Safari standalone web app (iOS home-screen web app) does not AutoFill or save the admin token #4644

Client or integration

Area

Summary

Reproduction

Version

Operating system

Logs or error output

Screenshots and supporting files

Redacted configuration

Checks

리뷰 · 우선순위 48 / 80

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Dashboard: Safari standalone web app (iOS home-screen web app) does not AutoFill or save the admin token #4644

Description

Client or integration

Area

Summary

Reproduction

Version

Operating system

Logs or error output

Screenshots and supporting files

Redacted configuration

Checks

Activity

lidge-jun commented on Sep 14, 2026

리뷰 · 우선순위 48 / 80

x3M3x commented on Sep 14, 2026

lidge-jun commented on Sep 16, 2026

devin-ai-integration commented on Sep 24, 2026

lidge-jun commented on Sep 26, 2026

lidge-jun commented on Sep 26, 2026

lidge-jun commented on Sep 27, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions