You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Allow users to run it locally with optional WorkOS integration #3
The creation of the account failed with an ''account not found''. There's no way to use the app without log in, Im stripping it out in a fork just to try it out.
Even better, I removed it completely. Thanks for the source. I'd recommend reconsidering the login requirement,, it hurts your app's usability. But hey, you do you.
i am thinking of making it usable without an account, but it won't be able to do a lot of the things i want to be able to do when i work
i am building comet to make cross device development as seamless as possible. i don't want to use tailscale, so the only way i can secure sessions across devices it to authenticate the user.
there are other features like tunnels for accessing remote dev servers, eg if you are working on a vps but want to view a website you're building without deploying. the tunnels must be secure, which would require an account.
i hear the feedback about usability and access though, and would love to find a middle ground here
login for multi device is super valid and fine, making it a requirement could even be understandable if it worked at all...
anyway, app looks good, too bad that the response for this issue is "ask your agent to run dev server".
crazy days for software development
It would be great to let users decide whether they want to sign in.
I like how T3 Code approaches this: users can use Tailscale, communicate directly with devices on their local network, or choose another way for their devices to reach each other. A hosted, authenticated connection could then be offered as an optional feature for users who need cross-device access, secure tunnels, or a simpler managed setup.
That said, after looking through the code, it seems like the account system is responsible for more than just routing traffic between devices, so making authentication optional may not be a trivial change.
@sabari245 Yes, is not as easy, but is the correct decision for the product, it should allow users to run it localy by default, and make the log in integration optional. There's currently a dev mode for development that doesn't ask for log in, but it forces users to clone it in order to discover how.
That said, I really liked the app, the performance is really good thanks to GPUI, it's very refreshing coming from electron apps, so the author did an amazing job and is quite frustrating that he took this decision, especially because Comet already has most of the primitives needed for an account-optional mode.
If the author agrees I can make a PR with this changes:
The engine can run with no EdgeConfig: local SQLite/snapshots, journals, terminal/repo work, harnesses, and local uploads still work. The current “login required” behavior appears to come mainly from the desktop startup/UI gate: a default WorkOS client ID is always enabled, and the UI waits for SignedIn before assembling the engine.
Would this direction make sense?
Make “Local only” the default first-run mode.
Generate a stable local profile/device identity.
Start the engine without Edge/WorkOS.
Persist sessions strictly on that device.
Show a small “Local only — enable sync” indicator rather than a blocking login screen.
Make WorkOS an opt-in “Cloud sync” capability.
Login is required only when the user enables cross-device sync, remote device routing, presence, cloud attachment replication, or future hosted tunnels.
Keep the existing WorkOS/Edge flow unchanged for that mode.
Keep local and cloud data isolated.
Do not reuse the current fixed dev-user/dev-org identity for end users.
Store local profiles separately from {org}/{user} cloud profiles.
Never automatically upload existing local sessions after login; offer an explicit import/copy action instead.
Treat switching modes as a controlled lifecycle event initially.
The current runtime is assembled with or without Edge, so the first version could ask for a restart after enabling sync.
Later, this could become a seamless runtime reassembly flow.
Keep direct/LAN/Tailscale as a separate future transport.
Tailscale solves reachability, but not pairing or authorization.
It should not reuse AUTH_MODE=dev, since that mode accepts non-cryptographic bearer identities and is only appropriate for local development.
This would preserve the security argument for multi-device sync and tunnels, while allowing someone to open Comet and use it immediately on one device.
Does “local-first, cloud sync opt-in” align with the product direction you have in mind? In particular, would you prefer local data to stay permanently separate from cloud data, or eventually support an explicit “move/copy selected sessions to cloud” workflow?
changed the title [-]App forces log in at start up, failed to create a new account.[/-][+]Allow users to run it locally with optional WorkOS integration[/+]on Aug 3, 2026
i am open to a PR to make comet accessible without account by default, and making account required only for sync/multiplayer features.
it was not my intention to make comet account only, but the account only features were what i cared about most so i didn't fully implement the version without the account. maybe i shared the repo too early, but i wanted to do this since it was always my plan to have this open source and many people were asking for the repo
as for the plan, i like most of it, the only thing i'm concerned about is the tailscale as future transport. atm the backend for sync heavily relies on durable objects, we would need a way to handle sync that is self hostable.
maybe this can be solved with a separate backend that is api compaitable? this is something i would want to implement down the line and not rush, but we should definitely keep it in mind
for signing in, maybe there can be a prompt that detects if use has local only sessions, and ask if they want to sync with the account they signed in with. if they decline, those sessions can be kept unsync and only accessible when they're signed out (or we have a mode to toggle between sync/non sync?)
Thank you for your answer, first, I need to apologize, sorry for my rude attitude, I was frustrated about the architectural decisions, specially because the app is very promising!
About your concerns, makes sense, and I agree that the important future boundary is not “Tailscale transport” specifically, but a sync backend that can eventually be self-hosted.
I would frame it as:
Keep Durable Objects as the first-party hosted sync implementation.
Avoid coupling the desktop/client sync logic directly to DO-specific assumptions where possible.
Define a small versioned backend contract for the operations the client actually needs: identity/device registration, workspace/document sync, presence/routing, attachment storage, and authorization.
A future self-hosted backend can implement that contract, even if its internal architecture is completely different from Durable Objects.
I would not try to build that self-hosted backend as part of the account-optional PR. But we can make choices now that avoid painting ourselves into a corner, like explicit backend capabilities/versioning, a configurable endpoint, and keeping the local-only path independent from the hosted backend.
On local sessions after sign-in, I think hiding them whenever the user is signed in would be surprising. I would keep them as explicit local workspaces/profiles that remain visible and usable alongside synced ones.
A first sign-in flow could be:
User signs in.
If local-only sessions exist, show a one-time prompt:
“You have N local sessions on this device. Would you like to sync any of them to this account?”
Let them select sessions/workspaces to copy or keep local.
Never upload anything automatically.
The UI could then show separate scopes, for example:
Local — stored only on this device
Account — synced with <org/account>
That also makes privacy and ownership clearer, and gives us a natural place for future import/export or self-hosted-backend support.
For the initial PR, I’d keep the scope small, local-first startup, stable local identity/storage, non-blocking sign-in CTA, and no Edge/WorkOS requirement until the user enables sync. Then we can iterate on migration UX and backend abstraction separately.
Let me know your thoughts, I can work on a draft for the first PR tomorrow and we can discuss the decisions and the scope with a draft in hand.
also thank you for the apology, i was a bit distressed but i understand the reason behind your frustration and i'm thankful for your desire to contribute
Don’t worry, I was the asshole here, and I’ll do better. Comet is young, and now, we can harness the power of the open source community. It's been a long time since I came across an ADE with this potential.
I have plenty of ideas for things I’d like to implement, so I’ll contribute as much as I can.
About this issue, I'll start working on a PR with the discussed scope, I'm still studying the source code so it will take a little while, I do not want to break any of the current integrations.
Activity
sabari245 commentedon Aug 1, 2026
facing the same issue, with login. unable to login with workos, it mentions user not found
sperictao commentedon Aug 1, 2026
same issue to me, is there any solution?
wing-anara commentedon Aug 1, 2026
login is temporarily disabled, in the mean time if you would like to use the application, you can ask your agent to try running comet as a dev user
jsgrrchg commentedon Aug 1, 2026
Even better, I removed it completely. Thanks for the source. I'd recommend reconsidering the login requirement,, it hurts your app's usability. But hey, you do you.
wing-anara commentedon Aug 1, 2026
i am thinking of making it usable without an account, but it won't be able to do a lot of the things i want to be able to do when i work
i am building comet to make cross device development as seamless as possible. i don't want to use tailscale, so the only way i can secure sessions across devices it to authenticate the user.
there are other features like tunnels for accessing remote dev servers, eg if you are working on a vps but want to view a website you're building without deploying. the tunnels must be secure, which would require an account.
i hear the feedback about usability and access though, and would love to find a middle ground here
ojowwalker77 commentedon Aug 2, 2026
login for multi device is super valid and fine, making it a requirement could even be understandable if it worked at all...
anyway, app looks good, too bad that the response for this issue is "ask your agent to run dev server".
crazy days for software development
sabari245 commentedon Aug 2, 2026
It would be great to let users decide whether they want to sign in.
I like how T3 Code approaches this: users can use Tailscale, communicate directly with devices on their local network, or choose another way for their devices to reach each other. A hosted, authenticated connection could then be offered as an optional feature for users who need cross-device access, secure tunnels, or a simpler managed setup.
That said, after looking through the code, it seems like the account system is responsible for more than just routing traffic between devices, so making authentication optional may not be a trivial change.
jsgrrchg commentedon Aug 3, 2026
@sabari245 Yes, is not as easy, but is the correct decision for the product, it should allow users to run it localy by default, and make the log in integration optional. There's currently a dev mode for development that doesn't ask for log in, but it forces users to clone it in order to discover how.
That said, I really liked the app, the performance is really good thanks to GPUI, it's very refreshing coming from electron apps, so the author did an amazing job and is quite frustrating that he took this decision, especially because Comet already has most of the primitives needed for an account-optional mode.
If the author agrees I can make a PR with this changes:
The engine can run with no
EdgeConfig: local SQLite/snapshots, journals, terminal/repo work, harnesses, and local uploads still work. The current “login required” behavior appears to come mainly from the desktop startup/UI gate: a default WorkOS client ID is always enabled, and the UI waits forSignedInbefore assembling the engine.Would this direction make sense?
Make “Local only” the default first-run mode.
Make WorkOS an opt-in “Cloud sync” capability.
Keep local and cloud data isolated.
dev-user/dev-orgidentity for end users.{org}/{user}cloud profiles.Treat switching modes as a controlled lifecycle event initially.
Keep direct/LAN/Tailscale as a separate future transport.
AUTH_MODE=dev, since that mode accepts non-cryptographic bearer identities and is only appropriate for local development.This would preserve the security argument for multi-device sync and tunnels, while allowing someone to open Comet and use it immediately on one device.
Does “local-first, cloud sync opt-in” align with the product direction you have in mind? In particular, would you prefer local data to stay permanently separate from cloud data, or eventually support an explicit “move/copy selected sessions to cloud” workflow?
Happy to hear your thoughts on this.
[-]App forces log in at start up, failed to create a new account.[/-][+]Allow users to run it locally with optional WorkOS integration[/+]wingleeio commentedon Aug 3, 2026
i am open to a PR to make comet accessible without account by default, and making account required only for sync/multiplayer features.
it was not my intention to make comet account only, but the account only features were what i cared about most so i didn't fully implement the version without the account. maybe i shared the repo too early, but i wanted to do this since it was always my plan to have this open source and many people were asking for the repo
as for the plan, i like most of it, the only thing i'm concerned about is the tailscale as future transport. atm the backend for sync heavily relies on durable objects, we would need a way to handle sync that is self hostable.
maybe this can be solved with a separate backend that is api compaitable? this is something i would want to implement down the line and not rush, but we should definitely keep it in mind
for signing in, maybe there can be a prompt that detects if use has local only sessions, and ask if they want to sync with the account they signed in with. if they decline, those sessions can be kept unsync and only accessible when they're signed out (or we have a mode to toggle between sync/non sync?)
jsgrrchg commentedon Aug 4, 2026
Thank you for your answer, first, I need to apologize, sorry for my rude attitude, I was frustrated about the architectural decisions, specially because the app is very promising!
About your concerns, makes sense, and I agree that the important future boundary is not “Tailscale transport” specifically, but a sync backend that can eventually be self-hosted.
I would frame it as:
I would not try to build that self-hosted backend as part of the account-optional PR. But we can make choices now that avoid painting ourselves into a corner, like explicit backend capabilities/versioning, a configurable endpoint, and keeping the local-only path independent from the hosted backend.
On local sessions after sign-in, I think hiding them whenever the user is signed in would be surprising. I would keep them as explicit local workspaces/profiles that remain visible and usable alongside synced ones.
A first sign-in flow could be:
“You have N local sessions on this device. Would you like to sync any of them to this account?”
The UI could then show separate scopes, for example:
<org/account>That also makes privacy and ownership clearer, and gives us a natural place for future import/export or self-hosted-backend support.
For the initial PR, I’d keep the scope small, local-first startup, stable local identity/storage, non-blocking sign-in CTA, and no Edge/WorkOS requirement until the user enables sync. Then we can iterate on migration UX and backend abstraction separately.
Let me know your thoughts, I can work on a draft for the first PR tomorrow and we can discuss the decisions and the scope with a draft in hand.
wingleeio commentedon Aug 4, 2026
your proposal and scope for this task sound good to me
wingleeio commentedon Aug 4, 2026
also thank you for the apology, i was a bit distressed but i understand the reason behind your frustration and i'm thankful for your desire to contribute
jsgrrchg commentedon Aug 4, 2026
Don’t worry, I was the asshole here, and I’ll do better. Comet is young, and now, we can harness the power of the open source community. It's been a long time since I came across an ADE with this potential.
I have plenty of ideas for things I’d like to implement, so I’ll contribute as much as I can.
About this issue, I'll start working on a PR with the discussed scope, I'm still studying the source code so it will take a little while, I do not want to break any of the current integrations.
jsgrrchg commentedon Aug 8, 2026
@wingleeio Sorry for the wait, I'm almost done with the changes, I'll submit the PR today.
fix(engine): turn-end delivery seal + deaf-sweep escalation (#1)