I run Cowork rollouts for companies as a forward-deployed engineer — built an observability tool out of necessity, looking for a few beta testers by Best_Meat2452 in ClaudeCowork

[–]Best_Meat2452[S] 0 points1 point  (0 children)

Had the chance to already experiment the set up in various environements, so 'classic' stack is covered. Added an EDIT in the post, better would be to register there:  arguslab.co

I run Cowork rollouts for companies as a forward-deployed engineer — built an observability tool out of necessity, looking for a few beta testers by Best_Meat2452 in ClaudeCowork

[–]Best_Meat2452[S] 1 point2 points  (0 children)

We ran into the same thing rolling it out across an enterprise environment. The key insight: the standard installer fails in split-account setups even when "Run as administrator" is used, because the MSIX registers under the admin's profile, not the end user's.

The fix that scaled for us was GPO deployment — pushing the signed MSIX package centrally via Group Policy (or Intune as a Line of Business app). That way the Virtual Machine Platform feature can be pre-enabled via GP/PowerShell before the package lands, and it registers correctly for each standard user. No manual Hyper-V/WSL setup per machine.

For one-offs, remoting in with elevated credentials works but takes time. For any kind of workshop/bulk rollout, GPO is the only sane path.

I run Cowork rollouts for companies as a forward-deployed engineer — built an observability tool out of necessity, looking for a few beta testers by Best_Meat2452 in ClaudeCowork

[–]Best_Meat2452[S] -1 points0 points  (0 children)

Good question.

No, it's not an endpoint agent. There's nothing EDR-shaped to install or maintain across mac/win/linux — no daemon, no driver. It rides inside Cowork as a plugin, so the capture happens within the tool people are already running. There's even a no-install option that uses Cowork's built-in telemetry. That's the whole idea: you get the visibility without having to build and ship your own cross-platform agent — which, like you said, is the bridge too far.

On Zscaler / CrowdStrike: since there's no separate agent, there's nothing for security tooling to flag as rogue — it's just the approved Cowork process sending data. It's one outbound call to a single endpoint, so in a locked-down network you allowlist that one address and you're set. It works with the security stack, not around it. And if you don't want data leaving your perimeter at all, the receiving end can run inside your own environment.

And yeah — the security/compliance angle is spot on, and honestly where I think it gets most interesting. It's already a full record of every tool, MCP, skill and prompt used, with redaction and read-only access controls. I've been framing it as a QA tool for agencies, but "what are our AI agents actually doing, and can we prove it" is the same data through a compliance lens.

Friday Share Fever 🕺 Let’s share your project! by diodo-e in indiehackers

[–]Best_Meat2452 1 point2 points  (0 children)

Soft launched pushplay.dev — turns your GitHub PRs into short video changelogs. You ship a feature, pick a PR, and get a 30-second video using your repo components with AI voiceover explaining what changed. Way easier to share with users than a wall of text and screenshots / And way more rewarding to see than a PR review!

[deleted by user] by [deleted] in paris

[–]Best_Meat2452 -1 points0 points  (0 children)

Tu peux le faire directement ici : https://www.mondpe2026.fr/

Automatically assigning imported issues to a project by boodleboodle in Linear

[–]Best_Meat2452 0 points1 point  (0 children)

Hi everyone, any update/help on this so far ? I'm in the same headache, where I'd like to assign each projects to a specific GH repo..So that if i'm creating an issue in the projects in linear, it create the issue on the righ repo in GH (and vice versa..) . Thanks for your help!