Diagnostic prompts

Debug and fix my TEC-CoWork Cloud MCP connection. It may be pointed at a stale or local server instead of my real TEC-CoWork Cloud server. Work through ALL phases, show your findings after each, and ask before anything destructive. Never print bearer tokens or Authorization headers — redact them.

My expected cloud web URL: https://cowork.te-consulting.at (replace with your self-hosted Den web URL if you run your own).

## Phase 1 — Evidence: what am I actually connected to?

1. Print the `openwork-cloud` MCP entry's `url` (redact headers) from every config you can find:
   - `~/.config/opencode/opencode.json`
   - any `.opencode/opencode.json` or `opencode.jsonc` in the current project
   - your own runtime config if you have an export tool
2. Inspect these files if they exist (they can silently override server URLs beneath the Settings UI), but report only `baseUrl`, `apiBaseUrl`, `requireSignin`, and `writtenAt`. Never print `handoff`, `claimLinks`, grants, tokens, or other credential-bearing fields:
   - `~/.config/de.tecwork.tec-cowork/desktop-bootstrap.json` (Linux)
   - `~/Library/Application Support/de.tecwork.tec-cowork/desktop-bootstrap.json` (macOS)
   - `%APPDATA%\de.tecwork.tec-cowork\desktop-bootstrap.json` (Windows)
3. If the url from step 1 is a localhost address, find what serves that port:
   - `lsof -nP -iTCP:<port> -sTCP:LISTEN`
   - for each PID: `ps -p <PID> -o pid=,command=` and `lsof -a -p <PID> -d cwd -Fn | tail -1`

## Phase 2 — Probe both servers directly (no auth needed)

4. The server from Phase 1, through the Den web proxy:
   `curl -s -m 5 <that-origin>/api/den/openapi.json | python3 -c "import json,sys; d=json.load(sys.stdin); ps=[p for p in d.get('paths',{}) if 'google-workspace' in p]; print(len(ps)); [print(p) for p in ps]"`
5. The expected cloud web URL, same command. Compare the two lists.

## Phase 3 — Probe through your own MCP tools (in-band ground truth)

6. Call search_capabilities with {"query":"google workspace","limit":10} and report the match names.
7. Call execute_capability with {"name":"getCapabilitiesGoogleWorkspaceCalendarEvents"} and report the exact error or result shape.

## Phase 4 — Diagnose

State which world you are in:
- openwork-cloud url is localhost/127.0.0.1, OR search returned only gmail-drafts, OR execute returned unknown_capability → you are bound to a STALE server, not the expected cloud.
- a desktop-bootstrap.json contains localhost URLs → that file is the root cause (it is the desktop app's Cloud URL source of truth).

## Phase 5 — Fix (confirm with me before each destructive step)

8. If a desktop-bootstrap.json contains stale/localhost URLs: show it, then delete that file.
9. If a stale local server process is still listening: show the process, then stop it, so nothing can silently serve old answers again.
10. Tell me to do these steps in TEC-CoWork, then wait:
    - Restart the TEC-CoWork app.
    - In the affected workspace, open Settings → Extensions and click Refresh (re-mints the token and rewrites the Cloud MCP config).
    - Click Show hidden, then verify TEC-CoWork Cloud Control under Your apps.
    - Run Reload OpenCode config from the command palette.
    - Start a NEW task so it receives the current tool set.

## Phase 6 — Verify (run in the NEW session)

11. search_capabilities {"query":"google workspace","limit":10} → PASS = the full current capability set (calendar, drive, and gmail capabilities ranked on top), not just drafts.
12. execute_capability {"name":"getCapabilitiesGoogleWorkspaceCalendarEvents","query":{"timeMin":"<today ISO>","timeMax":"<+3 days ISO>"}} → PASS = real events, or a clean needs_connection / missing-permission message — NOT unknown_capability.
13. Print a final report: root cause, what changed, and the before/after of probes 6/7 vs 11/12.

Diagnose whether TEC-CoWork Cloud MCP tools are available in this workspace. Gather evidence only: do not modify configuration, authenticate, log out, remove anything, restart services, or print configuration-file contents.

## Phase 1 — Test the task's actual tools

1. Attempt to call `openwork-cloud_search_capabilities` with `{"query":"ServiceNow incident","type":"mcp","limit":10}`. Do not use documentation or explain alternatives. Record whether the runtime accepts the tool call and its exact non-secret result or rejection.
2. Attempt to call `openwork_extension_list_actions`. Record whether the runtime accepts the call. Do not infer tool availability from an answer to "list your tools"; models can omit or invent tools.

## Phase 2 — Find TEC-CoWork's exact OpenCode runtime

3. Detect whether this machine is Windows, macOS, or Linux.
4. Find the exact OpenCode executable used by the TEC-CoWork desktop app. Prefer the bundled executable in TEC-CoWork's `resources/sidecars` directory; do not assume an unrelated `opencode` on `PATH` is the same binary. If multiple TEC-CoWork builds are running, use the process associated with this task when that can be established safely; otherwise report the ambiguity.
5. Find TEC-CoWork's generated `runtime-opencode-config.json` beside the active `server.json`. Respect discovered `OPENWORK_SERVER_CONFIG`, `OPENWORK_RUNTIME_DB`, or XDG overrides. Typical locations are:
   - Windows: `%APPDATA%\tec-cowork\runtime-opencode-config.json`
   - macOS/Linux: `${XDG_CONFIG_HOME:-$HOME/.config}/openwork/runtime-opencode-config.json`
6. Report whether the runtime config exists and its last-modified time. Never display, copy, parse, or summarize its contents: it can contain Authorization headers and other credentials.

## Phase 3 — Run a safe fresh-process probe

7. From this task's workspace root, set `OPENCODE_CONFIG` to the discovered runtime config for the subprocess only, then run:
   - `<exact-opencode-executable> --version`
   - `<exact-opencode-executable> mcp list`
8. Do not run `mcp add`, `mcp auth`, `mcp logout`, `debug config`, or any command that changes or prints configuration. Do not use `--print-logs` if it could expose headers or tokens.
9. Report:
   - operating system
   - exact OpenCode executable path and version
   - runtime config path, existence, and last-modified time
   - whether `openwork-cloud` is listed
   - its exact status and non-secret error
   - whether the failing workspace is the primary managed workspace or may be a secondary workspace configured dynamically

Important: `opencode mcp list` starts a fresh process. Do not claim that it attaches to or tests the OpenCode server already running inside TEC-CoWork. Describe it only as a fresh-process probe using the same binary and generated config.

## Phase 4 — Classify the result

- Fresh probe omits `openwork-cloud`: the generated config is missing, the wrong runtime config was selected, or this is a secondary workspace whose MCPs are registered dynamically.
- Fresh probe reports `failed` or `needs_auth`: preserve the exact non-secret error; investigate token, endpoint, TLS, or authentication.
- Fresh probe reports `connected`, but Phase 1 rejects the Cloud tool: the stored endpoint and token work, but the live desktop engine or task has stale/missing tool registration.
- Both Phase 1 calls are rejected: investigate whether the running engine loaded the injected config and plugins, plus project/global tool-deny policy.
- The forced Cloud call works, but a natural request chooses documentation: tool exposure is healthy; investigate system-prompt steering.

Finish with a concise redacted report. Never reveal bearer tokens, Authorization values, cookies, passwords, API keys, local server tokens, or strings beginning with `ow_mcp_at_`.