Get a link you can share from Grok Bot or Grok Build

Grok Bot and Grok Build can, because each of them runs commands. The Grok app can't on its own: you save what it made and drop it on host0.

The Grok Bot docs are firm that the Bot and the Grok app are separate apps, so a paywall you hit in one isn't about the other. Grok Studio is gone as well: the Grok FAQ says it's no longer supported and points to Grok Build.

No. A page is something the Bot writes for people to read, and nothing a visitor does on it is saved. If reading is all they need, use a page: it takes one sentence to the Bot and no second account.

Keep pages for reports, dashboards and trackers only the Bot updates. Reach for host0 when someone should add data, when you're on a personal account and want to invite one person by email, or when the Bot built a real site rather than a page.

It should fetch the skill, ask you to approve a sign-in, and post the URL in the chat. We've worked that out from the Grok Bot docs and haven't run it on a real Bot yet.

• You send the setup prompt. The Bot works on its own computer, not the one in front of you.
• An approval card may come up before a command runs, depending on Auto Review. A warning that this shares data outside the chat is accurate, because the files go to host0. Check the folder, then allow it.
• The Bot shows a link and a short code. Links in a chat open in your system browser, so you approve there and type nothing into the chat.
• The URL comes back in the chat. Until you say otherwise, it's private.
• On an Enterprise team with a network allowlist, an admin has to add host0.ai and host0.app first. Other teams default to allow-all.

Once it works, make it stick: "Save the process we just used as a skill called Publish to host0." Private skills are one library across your Bots. If another Bot can't find it, turn it on for that Bot under Private skills in Connect apps.

The device login saves it to ~/.host0/credentials on the cloud computer, and every Bot on your account can use it from there. All your Bots share one computer, command-line credentials included, so separate Bots aren't a wall between projects.

• The Grok Bot docs say not to put an API key in a file on the computer, and to prefer their secure secret card. The skill's sign-in does write a file, and we'd rather you knew. If that's a problem, publish from Grok Build or the browser drop.
• Recover, Reset and some computer updates can remove a secret kept in a file. If a deploy asks you to approve a sign-in again, that's the likely reason, and approving again fixes it.
• To cut a key off, revoke it in your host0 dashboard. Deleting a Bot doesn't help, since files and sign-ins stay on the computer.
• A teammate's shared Bot usually works on your computer in your own chat, so it uses your key. In a Slack channel it has one computer of its own, and it publishes to whichever account signed in there.

A folder of static files, or one file a browser can open. A deck, spreadsheet or Word file it made won't publish alone, so ask for a PDF or CSV of it.

• A site: a folder with index.html at the top. A folder without one is refused, with a message that says so.
• One file: a PDF, image, HTML page, video, audio, Markdown, CSV or text file. That covers the images and MP4 clips a Bot creates.
• Size: on Free, a file can be up to 3 MB, so check a video first.
• A running server: host0 can't run server code, and the Grok Bot docs don't describe a public address for something running on its computer. Ask the Bot to move lists and forms to shared data, which needs no server.

Ask any of your Bots to publish that folder again. The deploy finds the app from .host0/state.json in the folder, so the URL stays put and unchanged files aren't sent twice.

Have the project live in /workspace, the shared folder the docs recommend for files you want to keep. They warn that temporary folders are replaceable and node_modules isn't saved, so a build may need a fresh install after a Reset.

With no state file, a deploy makes a new app at a new URL, which is also what happens if you move the work to Grok Build, because your machine and the Bot's computer don't share files. Give the slug from its URL to avoid it: "publish this as the next version of team-todos".

It should, at the same link, but settle the approval first. A card raised by a routine expires after 30 minutes, and an expired card means the Bot didn't do the action.

• Do the whole job once in chat, then save it as a skill.
• Add one narrow rule under Settings, General, Auto-review, Custom Rules: allow the host0 deploy in /workspace/reports, say. An Allow rule still lets the review stop on another reason.
• Test runs real work, so it publishes a real version. Use an app that isn't shared yet.
• Every run spends weekly Grok usage, and schedules must be at least five minutes apart. Daily suits this better than hourly.
• Tell the routine never to change who can open the app. The docs suggest keeping publishing behind approval, and an app that's already private is the lower-risk thing to automate.

No. @bot posts only a short confirmation, and the work and its results stay in your main Bot's chat in the Grok Bot app. Open the app to find the URL, and to approve the sign-in the first time.

Your post is public, so don't describe anything private in it. Tagging isn't available yet for X accounts based in Australia, the UK, the EU, Iceland, Liechtenstein or Norway, and @bot stays quiet on a post with a video or GIF. Chatting with your Bots in X Chat is a separate route, and it's still rolling out.

Because some profiles block the network or your home folder. The sandbox is off by default, so this only comes up if you turned it on. We read this from the sandbox docs and haven't run it.

The way round both the workspace limit and an unattended grok -p run, where nobody is there to approve a link, is the same: set HOST0_API_KEY in the environment first, which the skill reads before it tries to sign in.