fix: keep browser setup config-only

docs/browser-automation.md

@@ -53,7 +53,6 @@ ccs help browser
 ccs browser setup
 ccs browser status
 ccs browser doctor
-ccs browser doctor --fix
 ```
 
 Use `ccs browser setup` for the primary one-command setup path. Use `ccs browser status` for
@@ -124,21 +123,9 @@ That flow:
 1. enables Claude Browser Attach in the saved CCS browser config
 2. keeps the configured DevTools port normalized
 3. creates the configured browser user-data directory if needed
-4. tries to start a managed Chrome/Chromium attach session
+4. prints the exact browser launch command for the current platform
 5. re-checks readiness and reports the next step if Chrome still needs manual attention
 
-If you want the same remediation flow from the diagnostic command, use:
-
-```bash
-ccs browser doctor --fix
-```
-
-If you only want to save config and browser-directory state without launching Chrome:
-
-```bash
-ccs browser setup --no-launch
-```
-
 ## Launching Chrome For Claude Attach
 
 Claude Browser Attach needs a browser launched with remote debugging.

docs/project-roadmap.md

@@ -41,7 +41,7 @@ All major modularization work is complete. The codebase evolved from monolithic
 
 ### Recent Fixes
 
-- **2026-04-19**: **#1049** Browser setup now has a real remediation path instead of status/doctor-only guidance. CCS adds `ccs browser setup` as the primary one-command flow for Claude Browser Attach, supports `ccs browser doctor --fix` as a repair alias, shortens managed browser-path output to home-relative display paths where appropriate, and updates browser readiness guidance to point users at setup first while keeping browser doctor read-only by default.
+- **2026-04-19**: **#1049** Browser setup now has a real remediation path instead of status/doctor-only guidance. CCS adds `ccs browser setup` as the primary one-command flow for Claude Browser Attach, shortens managed browser-path output to home-relative display paths where appropriate, and updates browser readiness guidance to point users at setup first while keeping browser doctor read-only by default.
 - **2026-04-18**: **#1038** Legacy OpenAI-compatible provider writes no longer self-destruct on the next `ccs cliproxy restart`. CCS now preserves AI-provider-managed top-level sections such as `openai-compatibility` during CLIProxy config regeneration, and the legacy `openai-compat` manager now rewrites only its own YAML section instead of dumping the whole file and stripping the generated version header. Regression coverage now proves the legacy helper keeps the generated header intact and that OpenAI-compatible connectors survive regeneration.
 - **2026-04-16**: **#1030** Browser automation is now a first-class CCS surface instead of an env-only/runtime-only feature. CCS adds `ccs help browser`, `ccs browser status`, and `ccs browser doctor`; a dedicated `Settings -> Browser` dashboard tab for Claude Browser Attach and Codex Browser Tools; a new `browser` section in `~/.ccs/config.yaml`; explicit readiness/next-step messaging for attach-mode Chrome sessions; and Codex UI guidance that marks the managed `ccs_browser` entry as CCS-owned and redirects browser setup away from the generic MCP editor.
 - **2026-04-15**: **#969** Local CLIProxy bootstrap no longer depends on live GitHub reachability during normal dashboard and runtime startup. CCS now skips hidden auto-update lookups on standard CLIProxy bootstrap paths, fails fast with explicit `ccs cliproxy install` guidance when a service start needs a binary that is not installed locally, and keeps `ccs config` able to open the dashboard in limited mode instead of stalling behind blocked release downloads.