Skip to content

docs(adrs): the workspace profile can't open the workspace's own website #268

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
LeslieCBarry wants to merge 1 commit into from
Closed

docs(adrs): the workspace profile can't open the workspace's own website #268

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
22 changes: 22 additions & 0 deletions adrs/workspace-profile-site-link.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,22 @@
# The workspace profile can't open the workspace's own website

On a fresh install the workspace profile never gets written. Onboarding queues the
`workspace-profile` task, the agent runs, and it stops without calling
`write_workspace_profile`.

The session is told to read our site with `web_fetch` (`apps/agent/agent/lib/preamble.ts`).
That instruction is system-role (`instructions/task.ts`), and `webFetchAllowed` in
`lib/web-policy.ts` only accepts links that appear in user messages. The user message for
this task is the fixed text from `work("workspace-profile")` in `lib/dispatch.ts`, which has
no link in it. So every fetch is refused with "That URL is not user-linked or approved
documentation", the `web_search` tool refuses every call anyway, and the profile stays
empty. The sign-in sweep tries again after seven days and hits the same wall.

It matters because every other session opens with that profile. Without it the agent is
told not to guess what we sell.

I'd let `webFetchAllowed` accept the workspace's own website and the pages under it, using
the same `websiteUrl()` the preamble already builds. That opens one site the operator typed
in themselves, so I can't see what it breaks. Putting the full https link in the task's
message would also work, but it only covers the home page, not the pricing or product page
the preamble asks for. Happy to send the change if you'd like it.