AeroCloud

AWS IAM Identity Center (AWS SSO) and staged S3 workspaces for VS Code for the Web.

Enter an AWS access portal URL such as https://my-login.awsapps.com/start, approve the AWS login, choose an assigned account/role, and open a bucket or prefix in the Explorer. No permanent access keys or local AWS CLI are required.

Preview: successful login and S3 round-trip with a real account must still be confirmed. Live Chromium probes in us-east-1 on 2026-09-10 could read registration/token responses but could not read device-authorization/account-list responses. An optional trusted bridge is included for blocked browser requests. It is not deployed automatically. Arbitrary AWS organizations, regions, bucket policies and browser origins are not universally verified.

Use

1. Install the CI artifact aerocloud-preview.vsix with Extensions: Install from VSIX in VS Code for the Web.
2. Run AeroCloud: Check Browser Connection. Enter the IAM Identity Center region. The Output panel reports the actual extension-host origin and whether the OIDC and account endpoints return readable HTTP responses. Expected 400/401 responses prove transport, not authorization. If direct requests fail, deploy the optional bridge on infrastructure you control and use Configure Trusted Bridge, then rerun the check.
3. Run AeroCloud: Sign In and Open S3 Workspace. Enter your portal URL and SSO region, complete the normal AWS/company login and MFA, then choose your account and role. Enter the bucket name, its region, and an optional prefix. This needs s3:ListBucket on that prefix; it does not require listing all buckets.
4. Open an object and edit it. An ordinary editor save (Ctrl/Cmd+S, or VS Code's own autosave) writes an IndexedDB draft in this browser, not S3. The Source Control panel shows pending changes and a comparison against the original object.
5. Run AeroCloud: Commit Changes to S3 to stage dirty AeroCloud editor buffers and upload the pending objects. The status bar shows pending count and last successful S3 save.
6. Optional: AeroCloud: Toggle Autosave to S3 saves dirty AeroCloud buffers and uploads every 60 seconds; set aerocloud.autosaveSeconds to 30 for a shorter interval. This is off initially and after reload. Failures pause it. Background tabs can throttle timers; closing the browser stops uploads.

One connection is active per window. Drafts are isolated by portal, SSO region, account, role, bucket, bucket region and prefix. A Web Lock prevents two tabs on the same origin from writing the same draft store concurrently. Sign-out clears this extension's saved session and cached role credentials; it does not log you out of your company's AWS portal or revoke already issued AWS credentials. Local drafts remain available.

Browser drafts survive reloads in the same browser profile and extension-host origin. They are not a backup: private browsing, browser storage cleanup, origin changes, or quota eviction can remove them. A failed local save is surfaced as an error. Unsaved editor buffers remain subject to VS Code's own recovery behavior.

AWS prerequisites and CORS

The login must have an AWS account / permission-set assignment, with s3:GetObject and s3:PutObject for the objects and s3:ListBucket for the prefix. KMS-encrypted objects may also require the appropriate KMS permissions. An application-only portal assignment does not by itself grant AWS credentials.

For direct browser access, a bucket administrator must allow the actual origin printed by Check Browser Connection. The extension-worker origin can differ from https://vscode.dev. With the trusted bridge, bucket CORS is not required because S3 requests originate on the bridge. Example direct-access bucket CORS rule — replace the placeholder:

[
  {
    "AllowedOrigins": ["https://YOUR-ACTUAL-EXTENSION-HOST-ORIGIN"],
    "AllowedMethods": ["GET", "HEAD", "PUT"],
    "AllowedHeaders": ["*"],
    "ExposeHeaders": ["*"],
    "MaxAgeSeconds": 300
  }
]

ExposeHeaders: ["*"] is required for direct access to read ETags and check object metadata/encoding headers. Requests omit browser cookies; authorization uses temporary AWS credentials. CORS never grants IAM permissions. AeroCloud does not alter bucket policy or CORS automatically. If SSO endpoints are blocked, changing bucket CORS will not fix them; use the optional trusted bridge.

Save behavior and limits

• Existing objects use If-Match against the original ETag; new objects use If-None-Match: *. Conflicts remain staged and pause autosave. There is no force-overwrite fallback.
• After a conflict, use Compare Draft with Current S3 Object to inspect both versions. Copy your desired edits before discarding the draft; reopen the current object, apply those edits and commit against its new baseline.
• A commit is a sequence of object writes, not an atomic multi-file transaction or Git commit. Successful objects clear individually; failures remain. S3 Versioning, if already enabled on the bucket, controls retained versions.
• Edits made while an upload is in flight stay staged against the newly saved baseline. A lost response can leave an uncertain write outcome; the draft is retained for review.
• Objects up to 5 MiB are editable. Tagged and Content-Encoding objects are rejected to avoid losing tags or writing browser-decoded content incorrectly. Object ACL preservation, Object Lock controls, multipart uploads, directory buckets, access-point ARNs and endpoint overrides are outside this preview. Use buckets with ACLs disabled (bucket-owner-enforced ownership).
• Deletes and renames are deliberately unsupported in this initial version. Save As stages a new object, and Discard Staged Changes removes a local draft. Empty folders are virtual until they contain a saved object. Keys containing . or .. path segments are unsupported.
• Original object content is cached while open to preserve a stable edit baseline. This preview does not watch for remote changes; conditional writes detect conflicts at commit time.

Validate with a real account

Use a disposable object under a test prefix. These steps are intentionally user-run: CI has no AWS credentials.

1. Run the browser connection check and record the actual host origin and endpoint outcomes.
2. Sign in with your portal URL, select an assigned account/role, and list the test prefix.
3. Edit the disposable object and save in the editor. Confirm S3 has not changed, then reload the window and confirm the local draft survives.
4. Commit; independently verify the object bytes in S3. This is the first authenticated write confirmation.
5. Change the same object externally after opening it. Commit a draft and confirm the conflict is retained rather than overwriting the newer object.
6. Enable timed uploads, edit again, and verify an upload while the tab is active. Sign out or interrupt networking and confirm a failed upload retains the draft and pauses autosave.

Development and workflows

The browser entry point, VSIX layout, CI and release conventions follow AeroCode and aerofig. The runtime is plain browser JavaScript with no Node dependencies. A deterministic local-module bundler keeps vscode as the sole external dependency.

npm run build
npm test
npm install --no-save --package-lock=false playwright@1.62.1 @vscode/test-web@0.0.81
npx playwright install chromium
npm run test:browser
npm run test:host
npm run probe:aws
npm run package:vsix

CI runs the unit suite, bridge security/transport tests, Chromium draft-recovery/CORS tests, actual VS Code Web extension-host tests, unauthenticated direct/bridged AWS transport probes and VSIX packaging. Probes use invalid placeholders; they do not register a client, complete SSO, or touch a bucket. JSON output and host logs distinguish readable responses from network/CORS failures and are attached with the VSIX. These cannot substitute for a real-account test.

Publishing follows the shared Aero repository workflow:

• Successful CI pushes to main with app-code changes invoke bpcarson/actions to create and merge a patch-version PR when the change did not already choose a version. Only package.json is updated because this project has no lockfile.
• Version changes on main, or a manual Release On Version Bump run, verify the extension and create a GitHub release. Odd minor versions (including 0.1.x) use the pre-release channel; even minor versions use stable, following AeroCode's convention.
• Release creation calls Publish VSIX directly so releases made with GITHUB_TOKEN still get published. Published-release events and manual publishing of an existing tag are also supported.
• Publishing verifies the tagged source, packages and checks a versioned VSIX, saves a workflow artifact, and attaches it to the GitHub release. Marketplace publication runs when VSCE_TOKEN is configured; duplicate Marketplace versions are skipped on retries.

Repository settings must allow GitHub Actions to create/merge the version-bump PR and access the shared bpcarson/actions workflow. This configuration change does not create a release itself; a manual release run can publish the initial version after merge.

References: AWS device authorization, temporary role credentials, S3 CORS, conditional writes, VS Code web extensions.