Add custom "Open with" applications

.agents/skills/test-t3-app/SKILL.md

@@ -40,7 +40,7 @@ Treat the overall testing or implementation loop—not an assistant turn or one
 - Do not stop the server merely because one verification pass completed or because you are yielding a response to the user.
 - Before starting another environment, check whether the existing process and browser tab still serve the task. Reuse them when healthy instead of discarding useful state.
 - On a later turn, verify that the existing process is alive and reuse its printed ports and base directory. If it exited, restart with the same base directory; create a new pairing token only when the browser session is no longer valid.
-- Tell the user when a test environment remains available, including its non-secret web URL when useful. Never include a pairing token.
+- Tell the user when a test environment remains available, including its non-secret web URL when useful. Include a pairing token only when the user still needs to pair (see below).
 
 ## Authenticate the browser on the first navigation
 
@@ -50,24 +50,13 @@ Treat the overall testing or implementation loop—not an assistant turn or one
 4. Wait for the pairing exchange and redirect to finish before navigating elsewhere.
 5. Continue in the same browser context so its stored bearer session remains available.
 
-Treat pairing URLs as secrets. Do not copy them into final responses, screenshots, committed files, or durable logs. A pairing token is short-lived and single-use; opening the URL in another browser or opening it twice can consume it.
+Keep pairing URLs out of screenshots, committed files, and durable logs. When the user asked for a shared environment, the deliverable IS the full pairing URL — paste it in your reply, token and all; a bare origin is useless to them. A pairing token is short-lived and single-use; opening the URL in another browser or opening it twice can consume it, so never open a URL you handed to the user.
 
 ## Recover a consumed or expired pairing token
 
-Create another token against the same database and web URL as the running dev server:
+Run `node apps/server/src/bin.ts pair` from the repository root. It discovers the running dev server (worktree `.t3` first, same precedence as the dev runner) and prints a fresh `Pair URL` against the server's current web origin, including a `--share` tailnet origin. Pass `--base-dir <base-dir>` only when the server was started with `--home-dir`, using the identical path.
 
-```bash
-T3CODE_PORT=<server-port> node apps/server/src/bin.ts auth pairing create \
-  --base-dir <base-dir> \
-  --dev-url <web-url> \
-  --base-url <web-url> \
-  --ttl 15m \
-  --label agent-ui-test
-```
-
-Use the `Pair URL` from this command once. Derive `<server-port>` and `<web-url>` from the current dev-runner output, including any automatically selected port offset. Setting `T3CODE_PORT` keeps the administrative CLI from probing for an unrelated free port.
-
-Always pass `--dev-url` for a dev-runner environment so the generated pairing URL uses the current web origin. An explicit base directory stores runtime state in `<base-dir>/userdata`; the `<base-dir>/dev` fallback is only used by an implicit dev home. A worktree-local `.t3` counts as explicit, so its state lives in `<worktree>/.t3/userdata`. Use `auth pairing list` to inspect active token metadata; it intentionally cannot reveal token secrets.
+Tokens from `pair` carry standard client scopes. The startup pairing URL carries admin scopes; if the user needs Settings → Connections management (`access:write`), restart the server and hand over the new startup URL instead.
 
 ## Inspect or seed SQLite state
 

.env.example

@@ -1,12 +1,14 @@
 # Optional: T3 Connect source builds
-# Leave these unset to disable optional T3 Connect features in local source builds.
-# Release builds inject their public values at build time. Do not add server-side
-# secrets to this file.
+# `cp .env.example .env` enables T3 Connect against the production deployment.
+# These are the same public identifiers baked into official release builds, not
+# secrets. Remove or comment them out to build with cloud features disabled.
+# Do not add server-side secrets to this file.
 
-# Get these from the Clerk Dashboard under API keys, JWT templates, and OAuth applications.
-# T3CODE_CLERK_PUBLISHABLE_KEY=pk_test_...
-# T3CODE_CLERK_JWT_TEMPLATE=t3-relay
-# T3CODE_CLERK_CLI_OAUTH_CLIENT_ID=oauthapp_...
+# Production Clerk instance. To use your own, get these from the Clerk Dashboard
+# under API keys, JWT templates, and OAuth applications.
+T3CODE_CLERK_PUBLISHABLE_KEY=pk_live_Y2xlcmsudDMuY29kZXMk
+T3CODE_CLERK_JWT_TEMPLATE=t3-relay
+T3CODE_CLERK_CLI_OAUTH_CLIENT_ID=hzxSgY2cH10sDU2r
 
 # Optional: signed macOS passkey builds. The RP domain defaults to the Frontend API
 # hostname encoded in T3CODE_CLERK_PUBLISHABLE_KEY. Set the override only when Clerk
@@ -15,8 +17,9 @@
 # T3CODE_MACOS_PROVISIONING_PROFILE=/absolute/path/to/t3code.provisionprofile
 # T3CODE_CLERK_PASSKEY_RP_DOMAINS=example.clerk.accounts.dev,clerk.example.com
 
-# Get this from your relay deployment. `infra/relay` deploys update it automatically.
-# T3CODE_RELAY_URL=https://relay.example.com
+# Production relay. For a self-hosted relay, `infra/relay` deploys update it
+# automatically.
+T3CODE_RELAY_URL=https://relay.t3.codes
 
 # Optional: hosted app origin used by the CLI's out-of-band OAuth flow.
 # Defaults to https://app.t3.codes; override to test against a staging deployment.

.github/VOUCHED.td

@@ -11,9 +11,11 @@
 # Keep entries sorted alphabetically.
 github:adityavardhansharma
 github:binbandit
+github:chrisdeeming
 github:chuks-qua
 github:cursoragent
 github:gbarros-dev
+github:gfsaaser24
 github:github-actions[bot]
 github:hwanseoc
 github:jamesx0416
@@ -25,11 +27,14 @@ github:Noojuno
 github:notkainoa
 github:PatrickBauer
 github:realAhmedRoach
+github:saphid
 github:shiroyasha9
+github:StiensWout
 github:Yash-Singh1
 github:eggfriedrice24
 github:Ymit24
 github:shivamhwp
 github:jappyjan
 github:justsomelegs
 github:UtkarshUsername
+github:SunkenInTime