dsh-login-chatgpt

Readme

# dsh-login-chatgpt

English | [中文](README.zh.md)

DeepSeek Harness plugin that adds an `openai-codex-gptoauth` provider route and
an independent **ChatGPT Login** settings page. The route mirrors the installed
`openai-codex` catalog and uses Pi's official ChatGPT OAuth device-code flow; no
OpenAI API key is requested.

## Install

### Install from npm (recommended)

```sh
dsh plugin --profile web add dsh-login-chatgpt
```

To install a specific version:

```sh
dsh plugin --profile web add dsh-login-chatgpt@0.2.5
```

Package: <https://www.npmjs.com/package/dsh-login-chatgpt>

### Install from a local checkout (development)

```sh
git clone git@github.com:jiangliuhong/dsh-gpt-oauth.git
cd dsh-gpt-oauth
npm install
dsh plugin --profile web add "$PWD"
```

The bundle installs the authorization service and uses the `llm` and
`credentials` services supplied by the standard `web` profile.

Start Harness:

```sh
dsh web
```

## Use

1. Open **Settings → ChatGPT Login**.
2. Select **Login with ChatGPT**.
3. Open the displayed OpenAI authorization URL and enter the one-time code.
4. Wait until the settings page reports **Connected**.
5. In the conversation composer click **Select model**.
6. Click the **Model / Select model** row to open the full catalog.
7. Scroll to `openai-codex-gptoauth` and choose one of its GPT models.

The route appears in the conversation model selector, not on the **Models**
settings page.

The login grant is stored by the DSH credentials service under
`llm-pi-ai/openai-codex-gptoauth`. Model requests reuse that grant and its
refresh flow automatically. OAuth tokens are never returned to the browser;
only login status, the verification URL, and the one-time device code are
shown.

## Local login endpoint

The client bundle talks to a loopback-only helper on `127.0.0.1:3091`. The
helper accepts browser requests only from loopback origins. A port conflict
fails plugin startup rather than silently disabling login.

## Development checks

```sh
node --check index.js
node --check login-manager.js
node --check client.js
node --test login-manager.test.js
```

## Release

Set the version in `package.json` and `package-lock.json`, commit it, then push a
matching tag. Both `0.2.0` and `v0.2.0` tag forms are accepted:

```sh
npm version 0.2.1 --no-git-tag-version
git add package.json package-lock.json
git commit -m "release: v0.2.1"
git tag v0.2.1
git push origin main v0.2.1
```

The tag workflow runs checks, publishes the exact `package.json` version to npm
with provenance, and creates a GitHub Release through npm Trusted Publishing
(OIDC). After the initial package bootstrap, no npm token or local publish is
needed for subsequent releases.

## Acknowledgements

Thanks to the [LINUX DO](https://linux.do/) community for its continued support.