@hey-hey/cli 1.1.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +131 -0
- package/dist/index.js +157967 -0
- package/dist/index.js.map +7 -0
- package/package.json +83 -0
package/README.md
ADDED
|
@@ -0,0 +1,131 @@
|
|
|
1
|
+
# Hey Hey CLI
|
|
2
|
+
|
|
3
|
+
## Development
|
|
4
|
+
|
|
5
|
+
From this directory:
|
|
6
|
+
|
|
7
|
+
```bash
|
|
8
|
+
pnpm dev
|
|
9
|
+
```
|
|
10
|
+
|
|
11
|
+
This runs the local API server flow from source (`tsx src/index.tsx`).
|
|
12
|
+
By default (`heyhey` with no command), the CLI starts the local server and waits until `Ctrl+C`.
|
|
13
|
+
|
|
14
|
+
Other useful dev scripts:
|
|
15
|
+
|
|
16
|
+
- `pnpm dev:build` - TypeScript watch build to `dist/`
|
|
17
|
+
- `pnpm dev:run` - run the CLI directly from source
|
|
18
|
+
|
|
19
|
+
## Register `heyhey` command
|
|
20
|
+
|
|
21
|
+
From this directory:
|
|
22
|
+
|
|
23
|
+
```bash
|
|
24
|
+
pnpm run register
|
|
25
|
+
```
|
|
26
|
+
|
|
27
|
+
This builds `dist/` and globally links the package so `heyhey` is available in your shell.
|
|
28
|
+
|
|
29
|
+
## Verify
|
|
30
|
+
|
|
31
|
+
```bash
|
|
32
|
+
heyhey --help
|
|
33
|
+
```
|
|
34
|
+
|
|
35
|
+
Example invocation:
|
|
36
|
+
|
|
37
|
+
```bash
|
|
38
|
+
heyhey
|
|
39
|
+
```
|
|
40
|
+
|
|
41
|
+
Provider credential refresh:
|
|
42
|
+
|
|
43
|
+
```bash
|
|
44
|
+
heyhey credential refresh --provider codex --account default
|
|
45
|
+
```
|
|
46
|
+
|
|
47
|
+
## Agent Auth Mode
|
|
48
|
+
|
|
49
|
+
Agent runs can authenticate in two ways:
|
|
50
|
+
|
|
51
|
+
- Stored credential mode: if a credential exists for the selected provider/account, Hey Hey binds it and injects auth env vars for the provider CLI.
|
|
52
|
+
- Native CLI auth mode: if no stored credential exists, Hey Hey launches the provider CLI without injected auth tokens so the CLI uses its own signed-in state (for example OAuth/login done directly in `codex` or `claude`).
|
|
53
|
+
- Codex invocation compatibility: Hey Hey uses `codex exec --full-auto --json ...` (and `codex exec resume --full-auto --json ...`) so orchestrated runs avoid interactive approval gates while staying sandboxed.
|
|
54
|
+
- Credential refresh command: use `heyhey credential refresh --provider <claude|codex> [--account <accountId>]` to store/replace provider API keys used by agent runs.
|
|
55
|
+
|
|
56
|
+
## Agent Invocation Recovery Config
|
|
57
|
+
|
|
58
|
+
The CLI reads agent invocation recovery settings from:
|
|
59
|
+
|
|
60
|
+
- `HEYHEY_AGENT_INVOCATION_CONFIG_PATH` (explicit file path), or
|
|
61
|
+
- `HEYHEY_CONFIG_DIR/agent-invocation.json`, or
|
|
62
|
+
- default config location:
|
|
63
|
+
- macOS: `~/Library/Application Support/heyhey/agent-invocation.json`
|
|
64
|
+
- Linux: `~/.config/heyhey/agent-invocation.json`
|
|
65
|
+
- Windows: `%APPDATA%\\heyhey\\agent-invocation.json`
|
|
66
|
+
|
|
67
|
+
Example:
|
|
68
|
+
|
|
69
|
+
```json
|
|
70
|
+
{
|
|
71
|
+
"agentInvocation": {
|
|
72
|
+
"errorVerbosity": "compact",
|
|
73
|
+
"model": "claude-sonnet-4-6",
|
|
74
|
+
"reasoningEffort": "medium",
|
|
75
|
+
"retryPolicies": {
|
|
76
|
+
"claude": {
|
|
77
|
+
"maxAttempts": 4,
|
|
78
|
+
"initialDelayMs": 300,
|
|
79
|
+
"maxDelayMs": 5000,
|
|
80
|
+
"multiplier": 2,
|
|
81
|
+
"jitterRatio": 0.2
|
|
82
|
+
},
|
|
83
|
+
"codex": {
|
|
84
|
+
"maxAttempts": 3,
|
|
85
|
+
"initialDelayMs": 250
|
|
86
|
+
}
|
|
87
|
+
}
|
|
88
|
+
}
|
|
89
|
+
}
|
|
90
|
+
```
|
|
91
|
+
|
|
92
|
+
- `model` — default Claude model ID (e.g. `claude-opus-4-6`, `claude-sonnet-4-6`, `claude-haiku-4-5-20251001`). Overridden per-run via the `model` field on `LocalCreateRunRequest`.
|
|
93
|
+
- `reasoningEffort` — default reasoning effort (`low`, `medium`, `high`). Overridden per-run via `reasoningEffort` on `LocalCreateRunRequest`.
|
|
94
|
+
|
|
95
|
+
## Cross-Service Review Workspace Flow
|
|
96
|
+
|
|
97
|
+
The local runtime now supports preparing a multi-repository review workspace for cross-service code review runs.
|
|
98
|
+
|
|
99
|
+
API integration points:
|
|
100
|
+
|
|
101
|
+
- `POST /api/local/system/review-workspace`
|
|
102
|
+
- Request body:
|
|
103
|
+
- `sessionId` (string, required)
|
|
104
|
+
- `repositories` (non-empty array)
|
|
105
|
+
- `serviceId` (string, required)
|
|
106
|
+
- `serviceName` (string, required)
|
|
107
|
+
- `repositoryPath` (string, required)
|
|
108
|
+
- Response body:
|
|
109
|
+
- `workspaceRoot`
|
|
110
|
+
- `workspaceLayout` (`"symlink_tree"`)
|
|
111
|
+
- `allowedRepositoryRoots`
|
|
112
|
+
- `links` (service-to-symlink mapping)
|
|
113
|
+
|
|
114
|
+
Runtime behavior:
|
|
115
|
+
|
|
116
|
+
1. The UI creates a coding session for cross-service review, then calls `/api/local/system/review-workspace`.
|
|
117
|
+
2. The local server validates repository targets, canonicalizes roots, and creates a per-session symlink-tree workspace.
|
|
118
|
+
3. The prepared workspace response is used to launch `/api/local/runs` with `scope.mode="cross_service_review"`, `workspaceRoot`, and `allowedRepositoryRoots`.
|
|
119
|
+
4. Run creation/recovery persists `scope` on the local run record.
|
|
120
|
+
5. Runner execution resolves working directory from run scope:
|
|
121
|
+
- default runs execute in the mapped service repository
|
|
122
|
+
- cross-service review runs execute in the prepared symlink-tree `workspaceRoot`
|
|
123
|
+
6. Prompt reference validation enforces that resolved references stay within the run's allowed repository roots.
|
|
124
|
+
|
|
125
|
+
## Unregister
|
|
126
|
+
|
|
127
|
+
From this directory:
|
|
128
|
+
|
|
129
|
+
```bash
|
|
130
|
+
pnpm run unregister
|
|
131
|
+
```
|