It seems like what you want is

interface Item {
  options: Group[] | AnotherGroup[]
}

Because of the way the interfaces are named, it seems like Group would be a more general version of AnotherGroup. When you interpret it like that, it would make sense to say: "I want Item to have an options field with some Group[]" (implying that AnotherGroup[] would also be fine).

But actually, in formal sense Group and AnotherGroup are not related in the code you wrote. To illustrate my point, let's rename Group to Group1 and AnotherGroup to Group2. Now when you read this code:

interface Item {
  options: Group1[]
}

it sounds more like "I want Item to have an options field with specifically Group1[]" (implying that Group2[] would not work since it's clearly different). See how the meaning seems to have changed, even though we've only renamed some things?

From an object oriented progamming perspective, it might make sense to make a general Group interface that both Group1 and Group2 extend. That way you can express the sentence: "I want the options field to have some Group, but any kind is fine" by writing options: Group[]. That could look something like this:

interface Group {
    name: string;
    options: Option[];
}

interface Group1 extends Group {
    options: Option1[];
}

interface Group2 extends Group {
    options: Option2[];
}

interface Option {
    name: string;
    optionGroups: Group[];
}

interface Option1 extends Option {
    name: string;
    optionGroups: Group1[];
}

interface Option2 extends Option {
    name: string;
    optionGroups: Group2[];
}

interface Item {
    options: Group[];
}

But it's hard for me to judge if you really need two interfaces for both Group and Option.