[Bug]: t3 connect status reports "Exposure: enabled" for publish-only links without a tunnel

Open Beginner friendly
#33,962 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
72/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
node.js, typescript
Domain
cli

Research direction

Read apps/server/src/cli/connect.ts, especially formatStatus at the lines identified in the report, and compare its human-readable output with the JSON status fields. Start by checking how the formatter derives exposure and handles linkMode. Done means publish-only status clearly reports that no managed tunnel is available and agrees with t3 status about remote access being disabled.

Written by the indexing model from the issue text.

Description

Before submitting
  • I searched existing issues and did not find a duplicate.
  • I included enough detail to reproduce or investigate the problem.
Area

apps/server

Steps to reproduce
  1. Use a running CLI/background-service environment linked in publish-only mode. The CLI supports configuring this with t3 connect link --publish-only, followed by starting/restarting the server.
  2. Run t3 status --json.
  3. Run t3 connect status.
  4. Run t3 connect status --json.

Steps 2–4 were run against an existing affected environment. Fresh authorization and service restart were not repeated.

Expected behavior

The human-readable Connect status distinguishes activity publishing from a managed tunnel. For a publish-only link, it should explicitly say that remote access through T3 Connect is disabled and that reaching the environment requires a separate route.

It should agree with t3 status about whether Connect remote access is enabled.

Actual behavior

t3 status --json reports connect.enabled: false, but t3 connect status says Exposure: enabled and Environment link: provisioned. It does not display the publish-only mode or explain that there is no managed tunnel.

The JSON Connect status identifies the actual mode as publish_only with reachability: null.

This led us to investigate a supposed T3 Connect outage when a desktop client's saved Tailscale route stopped working with Tailscale disconnected. The requirement for a separate route in publish-only mode is expected; the misleading CLI status is the defect reported here.

Impact

Minor bug or occasional failure

Version or commit

Observed CLI/server: 0.1.8-nightly.20261109.4433.

The same formatting is present on main at 047d492736ef7ad6c46250b52afafbd0b731f32f; that checkout was inspected, not executed.

Environment

Host: Ubuntu 26.04 LTS, Linux x86_64, T3 background service. Client: Windows desktop, same T3 nightly version, using a saved Tailscale HTTPS route. No provider/model invocation is involved.

Logs or stack traces

Relevant output, with unrelated fields omitted:

$ t3 status --json
{
  "connect": {
    "enabled": false,
    "revoked": false
  }
}

$ t3 connect status
T3 Connect
  Exposure: enabled
  Authorization: stored credential
  Environment link: provisioned
  Relay: https://relay.t3.codes
  Publish agent activity: enabled
  Relay client: available via PATH
    Path: /usr/local/bin/cloudflared
    Version: 2026.7.3

$ t3 connect status --json
{
  "desired": true,
  "authenticated": true,
  "linked": true,
  "revoked": false,
  "linkMode": "publish_only",
  "reachability": null
}

Source inspection: formatStatus in apps/server/src/cli/connect.ts derives the exposure label solely from status.desired. The same formatter omits the entire reachability section when status.linkMode !== "managed", leaving no human-readable explanation of the missing tunnel.

Screenshots, recordings, or supporting files

CLI output is included above.

Workaround

Use t3 connect status --json to inspect linkMode, and t3 status to check whether Connect remote access is enabled. Keep the separate network route available for a publish-only environment.

No configuration changes or service restarts were performed during diagnosis. Enabling a managed tunnel with t3 up --connect was not tested as part of this report.

Related: #11899 concerns desktop detection/repair of a drifted relay link; #31534 concerns enabling iOS Live Activities over a publish-only link. This report concerns CLI status output for an intentionally publish-only environment.

Report prepared by GPT-6.1 Sol via the Codex harness in T3 Code.

Dominant language
TypeScript
Stars
24.8k
Forks
6.4k
Avg merge
13h 9m
Merged PRs (30d)
187

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from pingdotgg/t3code

All issues in pingdotgg/t3code

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.