feat(channels): generic chat box with lazy repo attach

[raquelmsmith]

video explanation

https://www.loom.com/share/f352af8d74194f7a9c9e5d2010b6f00f

What & why

In the channels experience, this drops the up-front repo/branch picker. A channel task becomes a generic chat box: it can be a coding task (needs a repo), an analysis task (PostHog MCP, maybe no repo), or a non-code task like sending an email (no repo at all). The agent decides at runtime whether it needs a repo, clones one only when needed, and asks the user (via the built-in AskUserQuestion tool) when it can't determine which repo to use. Candidates = all repos, prioritizing those named in the channel's CONTEXT.md.

Mirrors how the Slack bot behaves (that repo-inference lives in PostHog/posthog), but implemented here. Works in local/worktree mode (for dev testing) and cloud mode.

How it works

UI (channel-only allowNoRepo)

• WebsiteNewTask → TaskInput hides the repo/folder picker, branch selector, env selector, and additional-dirs button, and removes the submit gate. The workspace-mode select stays (so you can run local). /code/ is untouched.

Task creation / saga

• A repo-less local task no longer skips the agent session — it starts in a per-task scratch dir (ensureScratchDir). No repo ⇒ no workspace, no clone.
• workspace.verify treats an existing scratch dir as valid (no spurious "working directory no longer exists").

Agent

• channelMode is derived server-side from the scratch path (isScratchPath), so it survives reconnects with no client plumbing.
• Adds a channel system-prompt (lazy-repo guidance) and two local tools gated on channelMode:
  • list_repos — lists candidates via gh
  • clone_repo — clones into <cwd>/repos/<owner/repo> (a scratch subdir, no cwd rebind, conversation preserved)

Scope / follow-ups

• Cloud channel tasks rely on the existing cloud "No Repository Mode" prompt; the new list_repos/clone_repo tools are local-only for now.
• Django: confirm PostHog/posthog accepts a no-repository cloud Task/TaskRun before relying on cloud channel mode (out of scope for this repo).

Testing

• ✅ pnpm typecheck (22 pkgs), biome lint clean
• ✅ Unit tests: core (1568, incl. a new repo-less saga test), workspace-server (478), agent (734)
• ⏳ Live in-app E2E not yet run — recommend: open a channel → "+", confirm no repo picker; submit an analysis prompt (no clone); submit a coding prompt without naming a repo (→ list_repos/AskUserQuestion); then name a repo (→ clone_repo).

---

Created with PostHog Code

[github-actions]

React Doctor found no issues in the changed files. 🎉

_{Reviewed by React Doctor for commit d5c88e3.}

[greptile-apps]

Security Review

• GitHub token embedded in clone URL (clone-repo.ts lines 63–65): the token is interpolated as basic-auth in cloneUrl. If CloneSaga surfaces the URL in result.error, the token is returned to the LLM in the tool result and may be stored in conversation history or server-side logs. The sibling list_repos tool correctly injects the token via GH_TOKEN env var instead.

Prompt To Fix All With AI

Fix the following 3 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 3
packages/agent/src/adapters/local-tools/tools/clone-repo.ts:63-73
**Token leakage via clone error messages**

The GitHub token is embedded directly in `cloneUrl` as basic-auth (`x-access-token:${token}@...`). When `CloneSaga` fails — on a network error, DNS failure, or an HTTP 4xx/5xx from GitHub — some git backends propagate the remote URL verbatim into `result.error`. That string is then returned as the tool result (`fail(\`clone_repo failed: ${result.error}\`)`), which lands in the LLM's conversation context and is potentially logged or stored in the agent transcript.

The `list_repos` tool next door uses the safer `GH_TOKEN` environment variable for `gh`, which never appears in error output. Consider the same approach here: configure git's credential helper or `GH_TOKEN` via the process environment (as `CloneSaga` may already support), and construct `cloneUrl` without the credential in the URL — fall back to `https://github.com/${slug}.git` and let the env-supplied credential flow through git's own credential handling.

### Issue 2 of 3
packages/agent/src/adapters/local-tools/tools/clone-repo.ts:67-74
**No guard against re-cloning an existing directory**

`targetPath` is deterministic (`<cwd>/repos/<owner>/<repo>`), so if the agent calls `clone_repo` twice for the same repo — during a retry, an LLM confusion loop, or a reconnected session — `CloneSaga` will attempt to clone into a directory that already exists. Git aborts with "destination path '…' already exists and is not an empty directory", which the agent receives as an opaque error and may misinterpret.

A simple pre-check would let the tool return the existing path immediately: if `targetPath` already exists and is a non-empty git repo, skip the clone and return the path directly (possibly also checking out `branch` if requested). This makes the tool idempotent and avoids confusing the agent.

### Issue 3 of 3
packages/workspace-server/src/services/workspace/scratch.ts:21-23
**Path separator assumption may miss Windows paths, and `isScratchPath` is too broad**

`workingDir.split(path.sep)` splits on the OS separator, which is correct on the current platform. However, the agent's cloned repo lives at `<scratchDir>/repos/<owner>/<repo>`, and once the agent `cd`s into that repo, the working directory passed to future sessions would still contain `posthog-code-scratch` — so `channelMode` would remain `true` for the cloned-repo sessions, which is the intended behaviour.

The broader concern is that any path on the system that happens to contain a directory named `posthog-code-scratch` — a coincidence or a malicious symlink — would silently enable channel mode and expose `list_repos`/`clone_repo` to a normal coding session. The check would be more precise if it also verified that `scratchBasePath(worktreeLocation)` is an actual prefix of `workingDir`, rather than just scanning for the folder name as a component anywhere in the path.

_{Reviews (1): Last reviewed commit: "feat(channels): generic chat box with la..." | Re-trigger Greptile}

[greptile-apps]

_{Reviews (2): Last reviewed commit: "fix(channels): address Greptile review o..." | Re-trigger Greptile}

[charlesvien]

Pulled, tested, committed a few fixes/safety guards/reused some existing utils we have.

I'd be comfortable merging from a "does this break Code" standpoint. I also tested cloud runs locally by building the agent package changes to my local background agents running on docker containers and everything appears to work as expected.