Coding Assistants in a Workspace

A Jupyter Lab or VS Code workspace can come with a command-line coding assistant ready in its terminal: Claude Code, Codex or OpenCode. The assistant works on your project's code and data where they are mounted, can run and test what it builds on the workspace's ports, and knows how to use the platform through the Strongly skill. This page walks through Claude Code; Codex and OpenCode work the same way.

1. Choose the assistant

When you create the workspace, open the Coding Assistants step and select Claude Code CLI. A workspace has one coding assistant: selecting another one replaces it, and clicking the selected one again clears it. Under it, pick any of your own skills from the Skill Library that you want in the workspace; only the skills you pick are added.

Every Jupyter Lab and VS Code workspace gets the Strongly skill and the skills you pick, for Claude Code, Codex and OpenCode alike, whether or not you select an assistant: an assistant you install or sign in to yourself later finds them too.

To change them later, open the workspace's Configuration tab and click Edit coding assistants in the Coding assistant card, where you choose one assistant or none. A change applies the next time the workspace starts or restarts: the assistant and skills are installed at each start, before the IDE opens.

If something cannot be installed, the workspace does not start, and the error at the top of its page says what and why, for example a skill that was deleted or is no longer shared with you. The Coding assistant card marks such a skill as unavailable; edit the card, click Remove unavailable skills, save, and start the workspace (or ask the skill's owner to share it again).

2. Sign in from the terminal

No API keys are supplied: the assistant uses your own account.

1. View the workspace and open a terminal (in VS Code: Terminal > New Terminal; in Jupyter Lab: File > New > Terminal).
2. Run claude and follow the sign-in steps it shows. It prints a link to open in your browser and asks you to paste back the code you receive.

The sign-in is kept in your home folder, which is not kept when the workspace stops. Sign in again after each start or restart. Your code, data, /workspace folder and unsynced work are kept as usual; only the assistant's sign-in and settings start fresh.

3. Where the skills are

Assistant	Skills folder
Claude Code	~/.claude/skills
Codex	~/.agents/skills
OpenCode	~/.agents/skills (the workspace sets OPENCODE_DISABLE_CLAUDE_CODE_SKILLS, so OpenCode sees each skill once rather than also in ~/.claude/skills)

The Strongly skill is in the strongly folder; each skill you picked has a folder named after it. The Strongly skill is downloaded from GitHub at every start, so it is always the current version; if GitHub cannot be reached, the workspace does not start and its page says why. Your own skills are reinstalled at every start too, so a change to one of your skills in the Skill Library reaches the workspace at its next start. A skill you add to the folder by hand is left alone, but like the rest of the home folder it is not kept when the workspace stops.

Claude Code may read both skill folders without asking: each workspace writes ~/.claude/settings.json listing them as additional directories, since a skill's files sit outside the folder Claude Code works in. The file is written at every start, so a change you make to it lasts until the workspace stops.

You don't need to name the Strongly skill: ask for something on the platform ("deploy this as an app", "list my add-ons") and the assistant uses it.

4. Work in the project's code

Start the assistant in your project's code folder so it edits what is saved to the volume:

cd /volumes/local/<project volume>/code
claude

The project's data is beside it in /volumes/local/<project volume>/data, and shared volumes are under /volumes/shared/. See Volumes.

Calls the assistant makes to the platform API from the workspace ($STRONGLY_API_URL/api/v1/...) are made as you, with no API key, and can do what you can do. A link it gives you to open in your browser starts with $STRONGLY_BASE_URL, the platform's public address.

5. Test what it builds

Ask the assistant to run the app it built on a port of its choice (for example 3000), listening on 0.0.0.0. Then open the workspace's Ports tab, enter the port and click Open. See Workspace Port Access for the details, including the X-Forwarded-Prefix header that lets the same app work unchanged once deployed.

6. Save and deploy

The assistant's changes are in the workspace until you Sync. Sync commits and pushes the project volume's code (a shared volume's code is read-only, so it is never pushed) and saves the data files you changed, each as a new version, in every volume you may write. Then deploy the app from the volume: see Deploying an app you built in a workspace.

If Sync reports a conflict (someone else changed the same lines since you last synced), decide each file on the workspace page, or merge it by hand in the IDE, then Sync again. See When someone else changed the same lines.